- [Host] The private sector has a distinct advantage in helping law enforcement attribute and stop cyber criminals. Cyber crime attribution is not always a clean cut game of cat and mouse like the movies and newsworthy FBI investigations of Russia and Chinese hackers. Sometimes it's meticulous work on the part of security professionals in dark corners of office buildings that prevent serious loss and reputational damage to major companies. This is the story of unsung security heroes that prevented major damage of an e-commerce platform, both by stopping fraud, and separately, attributing the ransomware permanently, each taking a security incident and preventing it from becoming a larger breach. This is the third episode of "Know Your Adversary".

- [Shawn] Yeah, I think about one case that really comes to mind and it was my entry into the world of security operations.

- [Host] This is Shawn Valle. Shawn was previously Chief Information Security Officer at Rapid7, a cybersecurity company, and previously worked in a variety of security positions within private enterprise. One of his previous roles secured an e-commerce platform capability that was regularly being defrauded.

- [Shawn] I was responsible for a growing e-commerce product suite and I was responsible for security operations of this product suite. And we're talking, building things from the ground up. The technologies needed to be built up, the people, the processes needed to be built up. And I was in a new space. E-commerce was new to me, but one of the things that I inherited as I, as I took on this role, was the world of denial of service and DDoS, and I'd always heard and learned great things about DDoS from my favorite podcasts and security blogs, but I'd never lived it, in my experience. Next thing I know I'm seeing DDoS on a regular basis.

- [Host] A distributed denial of service attack is a malicious attempt to disrupt the normal traffic of a targeted server, service or network by overwhelming the target or its surrounding infrastructure with a flood of internet traffic. Think of an unexpected traffic jam clogging up the highway, preventing regular traffic from arriving to its destination. An example would be the previous WannaCry attacks in 2017 that shut down many companies for ransom payments on behalf of the North Korean government. But this was a different kind of denial of service.

- [Shawn] So what was really interesting as I started to learn, this e-commerce platform, really its cloud platform, was home to many different types of retailers. If you think about your nearby mall and the expensive wing of the mall, you know, all of those fashion stores, their e-commerce, their dot coms were likely running on this e-commerce platform. What's really interesting is, from time to time customers who would take our platform and build a custom web application on top of this platform, they would reach out to their support folks, and eventually it'd get to me and the team that I was building to say, hey, we're offline, and as we come to look at it, we're starting to see these DDoS attacks, and I, and truly distributed that these platforms are being taken down by many different avenues in many different angles. If you think about your concert ticket or your sporting ticket company, new tickets are about to go on sale. There's only so many tickets before that place is sold out. A lot of people wanna get tickets to that concert or that game or that gaming conference or whatever it may be. Or you think about the hot sneakers, right? What's really interesting is these fashion companies, they create these high ticket items, and they only create a small amount of them. And then they go and put 'em on sale with a big promotion. People wanna get these tickets before they sell out. They wanna get those floor seats. People want to get these hot shoes before they sell out because they wanna get that hot pair of shoes sometimes 'cause they just want it for themselves, other times because they're such a hot commodity, they can resell them on eBay for, for many, many more dollars. I didn't realize this, but this is where I started having to dig into the fact that, hey, this platform's going down, it's going offline, don't know why, it's taking our tech ops team many hours to figure out how do we resecure the servers, possibly re-IP the servers, move the applications over, basically try to evade whatever's attacking them. In the end, I started to learn this whole new space of bots that I had never experienced before. There are things known as ticket bots and sneaker bots. And it's this software that enthusiasts can buy, or some entrepreneurs can buy to try to buy these hot items and then put them on the market for an upsell. I found it really fascinating and interesting. It started to make sense very quickly to me what was going on. Wasn't necessarily an adversary trying to take a platform down, but truly an enthusiast who says, I want to get these sneakers before they sell out or I want to get these concert tickets before the floor seats sell out. And I thought it was absolutely amazing. I realized that we need to take some of our own budget to buy some of these tools, some of these bots, because they were cloud-based bots, but some of them were desktop software. So, we'd buy the desktop software and bring 'em locally, and I'd get some of the smart folks on our team to start kind of reverse engineering what these tools could do. And we started to see things that would spin up hundreds or thousands of headless browsers. And those browsers would all start trying to buy a product and put it in the queue. So someone could then go and do the checkout. And the hope was they'd get one pair or two pairs of these shoes before they'd sell out, or they'd get these tickets before the floor seats would sell out. Thought it was absolutely fascinating to learn the real world idea of a DDoS, but not necessarily from a malicious perspective, from an enthusiast perspective.

- [Host] This is a denial of service using bots to cut in the digital line, so to speak, and being able to buy cool merchandise like shoes, clothes and even concert tickets ahead of normal people waiting online to buy tickets the normal way where you refresh the browser before the 10:00 a.m. opening. But imagine not just one person cutting in line, imagine 10,000 people cutting in line and pushing average citizens back 10,000 spaces.

- [Shawn] That's exactly what it is. Some cases they wanna cut in line. In other cases, for any of us who've tried to purchase something online that goes on sale at a certain time, you know, that frustration to say, hey, these things go on sale at 10:00 a.m., I logged on at 09:59 yet it still sold out before I got there. So, they're the people who didn't want that scenario. So if you picture this, it's not just the one bully cutting in line. That could be dealt with 'cause, you know, one bully cuts in line and it pushes, you know, everybody behind them back one spot, right, if you think about that, if they find a way to cut in line, but what happens when that bully uses technology to multiply himself by 10,000? So, that's the, that's the impact. So if you think about this platform, it's just a bunch of servers. And these servers are stood up with load balancers and technology to make sure that the system stays up and running and people can purchase things, right? That's the whole purpose of it. And they're probably stood up to allow so many hundreds or so many thousands of users to be able to log in and purchase things. But they probably aren't built for the tens of thousands or the hundreds of thousands of users because that's just not the volume that normally goes in. If I use that scenario of the one bully who cuts in line, but this one bully finds a way to multiply himself by 10,000 or 100,000, think about all the people behind that person that gets pushed back 10,000 spaces or 100,000 spaces. Not only do those people get pushed back, but the system that needs to handle this queue gets overloaded. So again, if we use the analogy of waiting in line, say there is a hundred people waiting in line, but now you've made the line 10,100 people think about the problem that just occurred. All these people get pushed back 10,000 spots. Now they're out in the parking lot. They're even pushed all the way down the street. They're pushed around the block. And so as this bully comes in and pushes everyone back with these cool technologies, what ends up happening is the system that queues up all the users, it tips over and it crashes. And so the idea is like the users are trying to buy a thing just buy one product. In many cases, I just wanna get one thing. I just wanna make sure I get that one thing. But what ends up happening is the server ends up tipping over because the ops folks never realized, oh, we should've expected 10,000 or 100,000 people to log in.

- [Host] So imagine any big box retailer paying this e-commerce platform and indicating a big sale is about to happen. And let's say numerous big box retailers share servers to promote a singular vendor sale, or they're promoting different events and they're sharing the same servers on this e-commerce platform, and then this happens. Big problems.

- [Shawn] So our customers, you know, the actual retailers, and it could be maybe just one retailer that we are working with, or it could be multiple retailers that maybe they shared some servers together. But ultimately, first of all, the primary customer, who's having this big sale and notified all their customers of this new hot sale that was about to happen, those folks are excited to log in and purchase. The retailer's excited about this big sale that's about to happen. And then moments after the sale happens, the server crashes and people are getting 404s and 500s and other error messages that the server's offline.

- [Host] Were the denial of service perpetrators committing crimes that should result in the jail sentence? I'm not a legal professional to judge the efficacy of that, but this certain problem doesn't rise to the dollar amount lost that is meaningful for an FBI investigation, but they're certainly compromising the confidentiality, integrity and availability of data networks and systems and disrupting legitimate business operations. Like any security team working in the shadows, it was time to roll up their sleeves and explore what the adversaries are doing.

- [Shawn] Yeah, so, you know, there's nothing exciting or sexy about it, but what really starts is our team, right, as I mentioned the security operations team is working with the technical operations team to assess the web server logs, and so our team would get our hands on the web access logs, and web access log is gonna give us a little bit of data, but it's the data that we needed to start to understand what was going on. And we started to learn a lot of commonalities. We were seeing many aspects of Firefox spinning up. So, Firefox makes sense. A lot of people in the world use Firefox. So that wasn't necessarily surprising. But what we found was it was an outdated version of Firefox. So, Firefox had, you know, had been updated, and it was this version of Firefox that had been logging into the server was three or four versions back, yet there were thousands of users that were logging in with the same version of Firefox from many versions back. And we thought, well, that's curious. Sure, not everybody upgrades right away, but at the same time, this is an outdated version of Firefox, and we could also start to fingerprint that this was not a standard version of Firefox. It was a custom version of Firefox, as well. So we started to recognize some fingerprinting that would identify that, wait, this isn't just a user using Firefox or using maybe some type of plugin into Firefox or something unusual. And in some cases, depending on which tool users would utilize, we would, in some cases, see this same IP address spinning up thousands and thousands of browsers in a matter of seconds. And so we thought, sure, any person could spin up a few browsers locally or even create a local script to do something like this, but to spin up the thousands would need some extra horsepower and some real interesting scripting to spin it up. So we started to see these interesting facts. Some of them specifically were, hey, we noticed this similar browser used many, many times over in a browser that shouldn't be that common.

- [Host] So to recap, the company kept good web access server logs and with good forensics and threat analysis, were able to see outdated versions of Firefox with various plugins being used. And some of these outdated browsers would come from the same IP address to spin up thousands of browsers that would enable the cheats of cutting in line to the point where it'd knock over the e-commerce platform from service. So how did the security team make it stop?

- [Shawn] So, I'm telling a story that's, you know, several years old. So, we'll get to a final resolution in a little while, but at this time, we didn't have a web application firewall. We really didn't have great layer seven protections. So, giving a little bit of a teaser of what the long-term solution was, but how did we solve it in the near term? So, as we had many potential servers to run our platform on, our technical operations team would physically take the hosted application that our customers were running and literally move it to other servers, physical servers and re-IP those servers. So if you think about the technical challenges that come along with this is our technical team is physically moving data from one server to another. And in many cases there was always backup. So it wasn't that strenuous, but in some cases there weren't backups, so they had to manually move the data over and then they'd have to go into DNS either locally or through a hosted DNS server and start changing IP addresses because as we started to learn from the attack perspective, the attacks were specifically hitting the IP and taking that server down. So, the general thought was, let's get rid of that IP address, basically burn that IP address down. It's not usable ever again. Maybe we'll come back and use it many, many years from now, but that, that IP address is gone. So, the idea was re-IPing things and moving them to different physical hardware, some that may be more resilient to a large number of users than the servers that were originally stood up. So, that was the primary fix was to get the customer back online, get things re-IPed, and then obviously they would custom develop their own web store. That customer would then have to go back and make some changes in their store to make sure that all their DNS records were set up properly for this new IP address.

- [Host] Attribution often gets down to the nature of the threat. Threat is defined by capability plus intent. Capability was to cut in line, so to speak, with the intent to buy merchandise and tickets. Were the fraudsters taking this merchandise and going to resell them on the black market somewhere? Were they're trying to game the system to take advantage of the sale, or were they even enable to, because the e-commerce platform couldn't sustain the availability of the bots? What's important here is that sometimes attribution is the ability to stop fraudsters so they go spend their time elsewhere, and continue to maintain continuity of business operations. The greater context probably do not warrant further attribution into the identity, but certainly warranted engagement with threat actors to understand the tactics, techniques and procedures on how they're doing this fraud so proper controls could be put in place, such as building a web application firewall or WAF.

- [Shawn] The attribution of the who wasn't what mattered. What mattered most to us and our retail customer was that the platform was up, it was online, you know, the triad, confidentiality, integrity, and availability, right? So, right now, we're talking availability. It was really the prime security concern that was here was the availability. So, the concern from everybody was availability. It was not who's the attacker, right? If we were to say, as you mentioned a crime, who is the attacker here, we didn't care so much about that. So, that got me to ask questions like, wait a second, how come you don't care about who the attacker is? You know, from my perspective, I need to do a little bit of intelligence gathering here. I'd like to know the type of mindset that does this. And also I'd like to go a little bit further and maybe look at some open source intel to see, hey, who talks about this stuff out on the internet? Who's out on Reddit, who's out on Twitter talking about, you know, this new thing, this new hot thing that's, that's going to launch and how they're gonna try to get in the front of the line. And we started to stumble on folks who were out there excited to get to that front of the line and purchase these things, and in many cases, enthusiasts, and in other cases, they were resellers. So the business themselves, their focus was, let's just get this platform online. The focus is not on the attribution. The focus is we wanna sell all these products, and we want these products to sell out. That's what we care about. It took multiple of these scenarios. So when talking about one scenario, this happened quite a few times, and then we recognized what we need. We need some layer seven protections. We need something at the front of our environment to protect that. And so in the end, we, as the third party WAF, we put that in front to give us some layer seven protection. And then when we would see these attacks come in, we didn't need to keep the protection on at all times. The operations team liked to manually enable the WAF versus have it running at all times. They were able to flip a switch to ensure that, hey, we're under attack, and basically what would happen is WAF would kick in and the WAF would be tuned, one, to start looking for signatures that we've seen, but it's also got some intelligence behind it to protect things. I thought it was really interesting. Once we got a WAF in front of us, things started to quiet down and this story became kind of a history for us to talk about.

- [Host] Now, let's turn to a story that does warrant attribution identity. This is the story of a vulnerability researcher who wanted to get paid for discovering vulnerability. This is often a very sticky situation with enterprises. For context, many organizations have what's called a bug bounty program, meaning they will pay security researchers to scour the internet, looking for vulnerabilities to their internet-facing business applications. While many security researchers are ethical and go about disclosing vulnerabilities the responsible way by working with outside counsel discreetly and being open about their nonmalicious intent, there are others who want to remain anonymous and threaten public disclosure unless a payment is made.

- [Shawn] I do have a pseudo ransom story, and it actually goes back a few years, more disguised in the scenario of a bug bounty, but it wasn't quite a bug bounty because the story is that I didn't have a bug bounty program set up, but yet somehow we had a vulnerability that was discovered by a quote unquote security researcher who really wanted to get paid for finding this vulnerability, and I think it's, it is somewhat fascinating because it did turn into a pretty serious security incident that we had to address. It started with a member of my security operations team, my security operations manager, reaching out to me, letting me know that he was informed by a security researcher, that they were able to obtain some of our customer data through our platform. And the story was that they identified a weakness in our platform, well, actually a true vulnerability in our platform. And they were able to obtain a considerable amount of our customer data. And what the security researcher was ultimately saying is "There's a vulnerability in your system at the web tier. I was able to obtain records that were customer records and I have those records, and they are secure, and I will show you some of those records just to demonstrate that I was able to do that, but I would like to be paid X number of dollars for finding this vulnerability." And if we were to really dig into this if what they said was true, they hacked into our system and they actually stole customer data, which, in this case, would truly be considered a crime. So, as we started to have some conversations with this person who had reached out to us, they said that there was some content on Pastebin. Here, let me go point you to this location on Pastebin. And as our security operations leader, myself, we looked at the data that was on Pastebin, and lo and behold, publicly available to anybody that had this link was some of our customer information and some of our customer data, a snippet of it.

- [Host] Pastebin is an online content hosting service, where users can store plain text, such as source code snippets. It's often where hackers dump content from breaches as a testament they gained the unauthorized access and exfiltrated data.

- [Shawn] We immediately went into, as we call it, incident response mode. We have publicly leaked data. First, it started with someone who reached out to us in a public way. Secondly, they demonstrated that they have customer data. Third, they are, and again, we're using the word ransom. We didn't have ransomware in the current state of things, but somebody was asking for dollars for finding this vulnerability. And ultimately the scenario was to keep their mouth shut, so they wouldn't go public with this information. So, in my role, my responsibility was, okay, since their response time, we need to understand what's in front of us. We have to work with our leadership, our executive team to inform them. We need to work with our legal team. And then we also need to work with our customers who are impacted by this. So, we kind of spun up the traditional role of an incident response with an incident response commander, leader doing the traditional things. As we still worked on communications with this person, we obviously didn't wanna lose communications with this person, which started over email, by the way. It was truly just an email that came in and we had email comms back and forth. What was really interesting is this platform that I was working with at this time had thousands of customers on it. And the data that was shown to us was from seven customers, just a, just a handful of customers. I thought that was interesting. This person who gathered this data, why not get all thousands of them, why only get a handful of them? So that made things a little bit more curious. And, you know, we knew the data was legitimately our customer data. So we know the data was definitely publicly exposed and this person should not have had access to seven different customer's data. It's just, it's just unlikely that that was the case. And as we started to dig into it, I'm like, this is actually a custom URL and this custom URL is built by a third-party contractor. We started to do a little bit more digging. And in the end, why was there only seven customers that were impacted by this and not thousands of customers? Come to find out, a third-party partner of our company who builds custom applications for our customers, they built a custom implementation of our product and what they had was a vulnerability in their custom implementation. They had some text fields that did not have proper validation in them. And this security researcher found this exposed on one of our customer implementations and then did some searching to find common implementations. And he found seven of our customers that had custom applications. And so, in the end of the day, it was truly a vulnerability and a weakness in the product itself. But it wasn't our core application, 'cause that was one of the things I found very concerning as we started this investigation. We were relatively confident that our web tier was well-protected yet we saw this vulnerability, which showed that we weren't, we're not nearly as well-protected as we thought. And in the end it was a custom implementation. And so multiple customers that used this third-party contractor were ultimately exposed in this.

- [Host] This is pretty classic for any small and large enterprise who outsources web application development. And similar to last week's episode, speaks to the criticality of securing the digital supply chain. I can tell you from experience, there are few mature security teams that could have proactively detected something like this. How this happens in practice is it's very common for third-party developers to use their own infrastructure to store code and open-source repositories and use infrastructure that has vulnerabilities. To be honest, just like security teams have threat intelligence programs that scrape the internet for mistakes like this in code development, so do the bad guys, and the chances of them seeing this mistake before a security team are actually pretty good. This risk is very much still real. And usually it takes a two-part approach, finding the bad guy, and ensuring an event like this does not happen again. First, to ensure this doesn't happen again.

- [Shawn] So, I think you're onto something. And if you think about a lot of cloud platforms that exist now that allow customers to customize those, this risk is still real in many products that allow custom implementations on top of, of a core platform and in many cases, as companies are building out their information security teams and technology companies hopefully building out their application security components and their security engineering and product security folks, in many cases, as I've seen, companies are building those teams and bringing on the skill sets to assess the core applications, you know, the primary products that the companies sell, but aren't necessarily building out a functionality to assess third party add-ons, third-party components. And if I think about a model that has been very successful over the past 10 plus years, think about the Apple app store, right, the iOS app store, how there's, you know, a very thorough vetting process before an application gets approved, and it's vetted for many different things, but some of those things are weaknesses and vulnerabilities. And I think Apple was onto something with this vetting process to vet third-party applications before they are allowed into their store and if I think about corporate applications, enterprise applications that allow third-party code, a lot of folks have learned from that Apple model and a lot still have, have a lot to learn there which is, if you're allowing people to build custom code on top of your application, you should really be thinking about extending your Infosec reach, your application security reach into that third-party code, and not just leave it exposed and hope that your third parties are going to build a secure platform, 'cause in the end, the incidents will come back and you will be impacted by those incidents, in the end. We were very open and truly partnering with our customers. And that was one of my key focuses was to get to my counterparts at our customers and get to my counterparts' leadership, the counterpart leadership at, at our customer sites and to help navigate them through this and to help them kick off their own incident response and be a part of their incident response, right. That's who I, who I would work with for the majority of that. But there was a group of us who were off in our own internal war room trying to get to the root of this. And if I think about it, it was probably a handful of days, days and nights around the clock continuing this investigation as we got to the ground of it. So, it was probably the first week, as I said earlier, a couple of weeks, but I think it was probably within the first handful of days, probably two or three days before we recognized the commonality of these handful of customers were all built off of the same implementation.

- [Host] And now, to finding the bad guy.

- [Shawn] So, to make sure these multiple custom applications were either taken offline or the code was rewritten to make sure that that weakness was gone and working with our customers who, if you think about it, you know, we live in a trust-based world, this is a trust-based business that we're in. And so in some cases, trust had been broken with our customers. So, a lot of my focus was to ensure that we were there to partner with our customers and to keep that trust and rebuild that trust that may have been broken through these data exposures. I was not focused on the attribution, but if we were to think about some of the key components, right, there were folks in the team that were emailed by this so-and-so security researcher. So, if I think about folks who have gotten into the bug bounty world, some folks have done it the right way by going and working with a bug bounty company, as, you know, as a bug bounty security researcher. Others pay attention to the industry and see where there might be public bounties that are available and go and work those. So, the person who was involved in this, I don't know the details behind, you know, where the attribution was, but could very well have been a legitimate researcher who worked in other bounties, but also did a little bit of moonlighting on the side to try to get a little extra high value coin that maybe they couldn't have gotten from their bug bounty partners.

- [Host] You can see the difference in security events between the cut-in-line denial of service attack and the pseudo ransom incident that this is. This certainly rises to the level of attribution where the identity may be important to determine because no one wants him to do this kind of ransom event again. Peeling back his email address from where he was communicating from, looking at his attacker infrastructure, the Pastebin site he posted his document. And any telemetry we can gain from that are all starting places. Perhaps he reused an email address used to communicate with Shawn's team somewhere else. Perhaps he reused a password from other emails that gives a clue on his identity. All these are starting points.

- [Shawn] This was not the case of, hey, our retailers are excited that people are buying all their product out, and there's so many shoppers that their store crashes. This was a case of, wait a second, our data's exposed. This was a, you know, very, very different scenario. So, the thought here is, okay, one, we don't want this to occur again, and at the same time, who is going to be held accountable for this, right? There were folks who asked these questions. Some of our customers would ask these questions. And so are some of our customers were off doing their own investigations and even working with their local law enforcement to track things down. But I think you hit on a couple things that are very likely. There were email communications. So, we could do some research based on an email. And you know, where does this email track from? Can we, can we track down this email address? And as the data leak came from the malformed URL, right, so there was some enumeration, numeric enumeration on URLs, web access logs come into play again. So, the investigation of a web access log, and we did some investigation and we handed some of the data off to other folks in the team, and then some law enforcement folks of like, you know, here are the IP addresses that came in. And as we can tell, they were likely on a VPN because the IP addresses would change from time to time from some US-based IPs to some European based IPs. So, someone was attempting to cover their tracks, whether they were doing a great job of it in the end, it's a different story. So, in my role, I was ultimately focused with how do I help work with our customers to get closure? Our team was, was definitely involved in gathering some information to hand off to our executive team who was ultimately working with some law enforcement folks.

- [Host] So did they catch the guy?

- [Shawn] Did we catch the guy? I don't know, I don't know. Maybe, I don't know. I wasn't there. I'd love to think so.

- [Host] Shawn, of course, is being coy here and I'll leave it at that, and not prod too much as this is probably pretty confidential, but an important lesson in how to deal with these security events in the future. Reacting fast during security events can often result in avoiding breaches and reacting fast during breach incidents to inform customers and share information, both with customers and in, and law enforcement is the way to go. This is certainly a secrecy culture that will take some time to change, but we've been through enough security incidents to know that the more transparency, the better.

- [Shawn] You use the word, the B word, the breach word, right? It's a word that we, it's a sacred word. Only certain people can say it and really mean it. But in this case, it's how do you deal with it? And I think this was a really important example of us immediately saying we need to work with our customers right away. We need to inform our customers. We also need to work with our internal and external legal counsel for guidance on what must we report, what are we obligated to report and what should we report publicly? And I feel really good at the end of the day. We really did a thoughtful approach to disclosing to our customers and those in the public who needed to be informed. And in some cases it was our customers of our customers. And I think the most important thing is how do you deal with it? I think any of us who read any of the breach headlines really highlight the fact of the organizations that recognize they've got a nasty data loss or a nasty breach, and instead of coming forward, and letting the folks know that need to be informed whose data may have been impacted, instead try to cover it up and find ways to make it go away. It's really how you deal with it in the end. We live in a world that we're all connected, and our data may easily get into the wrong hands, or sometimes difficultly to get in the wrong hands but it still may happen in the end. What's most important is how we deal with it. And again, it's a, it's a trust-based relationship and we have to continue to think of it that way.

- [Host] Many thanks to Shawn Valle for coming on the show and sharing some dynamic security incidents and the responses enterprise should take with attributing adversaries and maintaining business continuity. Sometimes it's not attributing the identity that we all want, but it's knowing your adversary to get back to business as usual. Thank you for listening to "Know Your Adversary". Every other week, we will bring you a new cyber crime attribution investigation that is representative of the work of Nisos' operators past, present, and future. If you have any good stories to pitch, please reach out as no two investigations are the same and simultaneously fascinating how digital clues come together to bring context to crimes that victimize enterprise. For more information, please visit www.nisos.com. Thank you for listening.