I appreciate everyone taking the time for today's webinar. As far as the agenda, today, we'll start off with a brief overview of the product CrowdStrike. So, talking through the different modules that are available to you via your subscription. You may have a subset of some of these items. If you have any questions on any of the additions, feel free to let us know. We'll talk through some of the different aspects of support. There's a phone number that's available to you to give Dell a call if there are any questions about the CrowdStrike tool that you'd like to have addressed. From there, we'll talk through some of the different implementation planning aspects. Some of the things as we start to deploy CrowdStrike into your environment, we'll want to understand, or not.
I set up a set of things to think about from a deployment stance to ensure that as you start to leverage the tool, things go smoothly. Then for that, we'll also have some best practices surrounding how to configure the CrowdStrike console, the different stages that you may want to walk through. On top of that, we'll have an appendix. The appendix will reiterate a lot of the different talking points that I'll walk through today during our presentation. This slide deck will be shared with everyone on the line. So, you will have that handy in case you wanted to review any of the material. Then, from there, some next steps that we would recommend you go through to ensure that everything is getting set up properly for you.
Again, that said, if there are any questions that are outside of this scope, items that you wanted to discuss, please feel free to ping within the chat, and we can address those during the presentation. Let's talk quickly about the CrowdStrike product with just an overview of the different modules that are able to be leveraged directly within the console of the tool. First, from just an overview perspective, from the far left, we have the Falcon Prevent. This is going to be part of the security tool. Essentially, it's going to be the main protection aspect of the CrowdStrike antivirus tool.
This is going to be the antivirus, the ability for CrowdStrike to actually take action and block items that are deemed as suspicious within the console. On top of that, we have the Falcon Insight. That is going to be the driver of all of the detailed information that is delivered on the back end of CrowdStrike. Every time a process is executed on an endpoint where CrowdStrike is installed, Falcon Insight will identify the processes that might stem from that executable that was run. It'll track the start time, the stop time, the DNS request. There are probably around 100 events that are captured across the Mac, Windows, and Linux environments. Device Control. This gives CrowdStrike the ability for you to lock down your USB ports, so that users are only able to leverage USBs in a way that you control.
In other words, if you say that certain machines are allowed to use USB devices, such as mass storage devices, if you configure that. If you dictate that all of the computers, all of the machines across your environment should never be allowed to leverage a USB device, such as a mass storage device, you can also configure that. Falcon Discover. Through the information that we gather through the Falcon Insight tool, we are able to deliver information to you around the applications that are being used in your environment. We can also see the accounts that are being logged in to. Also, by scanning and scraping the ARP cache, we can see the devices that are being connected to from the device or from the network layer. Falcon OverWatch.
This is going to be a managed threat-hunting service available to you through CrowdStrike. CrowdStrike has a team of threat hunters that are actively looking for penetration or hands-on keyboard-type intrusion scenarios inside your environment. If they identify a scenario that looks suspicious in this manner, they may reach out to you with a full scope of what has taken place, timestamps associated with that activity, machines that might be affected, and information surrounding that type of manner. Falcon Spotlight. Spotlight is going to be a tool that gives you visibility into the different vulnerabilities that may be active in your environment due to missed patches from security updates from Microsoft. This could be an indication that we rank on a scale of how to prioritize patching some of these items, given what they protect against. Falcon X. This is going to be a merge of the sandbox tool that we see on the far right, and the Falcon Prevent tool, which we see on the far left.
If you're leveraging the Falcon Prevent tool in a quarantine mode, where if CrowdStrike identifies an executable inside of your environment, and you attempt to execute it, and we deem it as suspicious, we may quarantine that file. When that file is quarantined, it'll automatically be ported into our sandbox by way of Falcon X, detonated, and then a full report will be present for you to understand what would have taken place if that file were allowed to execute. Finally, Falcon MalQuery. This gives you access to CrowdStrike's malware database, which is fairly large in size, where you can search around, pull a suspicious file that you may have, see if we've already analyzed it in the past, and things of that nature. Of course, the Sandbox, I already explained. It's, essentially, the ability to upload files into a sandbox environment to be detonated on the platform of choice. That gives a broad overview of the different products available within the CrowdStrike portfolio. It's likely that you have just a subset of these items. At the end, do let us know if you have any questions on any of those.
Now, from a Support standpoint. Support from a Dell perspective is going to be available via a phone number. Here, you'll notice the phone number listed for the US, for the States. If you were going to try to contact us, or if you have a team that's trying to contact us from somewhere abroad, from an international location, there is going to be a listing at that link located here. Again, this deck will be available to you so that you have that information handy going into the future. Now, some of the implementation planning. We're at the stage of thinking about the deployment of CrowdStrike into our environment, and we want to think about some of the different key questions and considerations that come to mind as we start to think about introducing a new antivirus into our environment. The first question that comes to mind is, just generally speaking, what the plan is for full deployment.
Gaining a better understanding of whether we're going to be rolling out to workstations, servers, or both, having some type of a timeline identified. These are going to be some of the key items that I always generally think about when I'm about to introduce a new product into my environment. Another thing specifically related to CrowdStrike that we want to understand is what the current antivirus solution is inside of our environment. Is that solution going to be running side by side with CrowdStrike, or is it going to be phased out? This may be done in stages. Initially, we may look to install CrowdStrike, and immediately remove our pre-existing antivirus solution. We may look to do it a couple of months down the road.
The reason that I ask this, and chalk it up as a key question, is because later in this presentation, once we get into the "Best Practices" section, we'll talk through some of the different ideas around if we're running side by side with another antivirus solution, then there would be one way that you would want to configure the solution. If we're running solo without any other antivirus products present, we will want to go down a different road. There's different protection capabilities that we'll want to leverage with those two scenarios. Just make sure you have that clearly identified, and we'll reintroduce that idea here in about five minutes or so, once we get to that section. Some other considerations: What VPN is in use? Really, the only consideration there is if you have Junos Pulse present out of your environment, specifically an older version of the Junos Pulse or Pulse Secure agent inside of your environment. It may be having some type of conflict with the CrowdStrike agent. If you're running any other VPN client on your machine, this is not something to worry about.
If it is something you're running on your machine, we can include a link with this presentation so that you can read up on what the Pulse Secure team has to say, and what agent versions may be affected. As far as the advanced installation methods are concerned, with the CrowdStrike agent, there are two items that I want to specifically call out. These are referenced in our Deployment Guide, but are something that sometimes are missed. I just want to make sure to call this out clearly so that you are aware. First, is a tamper-proof password protection that can be leveraged at the time of install. When you install CrowdStrike into your environment, there is the ability to put a lock on it so that it cannot be uninstalled unless a password is present. Do keep that in mind. If you install the agent, and you want to go back in time, or if you want to then, at a later point, install this password protection, that's present as well.
That capability is available. But again, this is just something to consider, whether or not you want to have that tamper-proof setting in place. Because anybody with admin rights, or elevated admin rights, has the ability to uninstall the agent if they so please, unless that password parameter is present. The other item is answering the question of whether or not you're going to be installing on any virtual machine templates. The reason for this is that there may be special install parameters that you also want to leverage here, and they will range, if it's a persistent image that might require one switch. If it is a non-persistent image, it may be a different one. Again, all of this information is detailed out in a pretty specific fashion, inside of the CrowdStrike Deployment Guide, specifically surrounding Windows for those two items, and then Mac, as well, for the password protection.
As far as single sign-on is concerned, CrowdStrike is also SAML 2.0 compliant, meaning that if you wanted to leverage your SAML product, or single sign-on product, to log in to the CrowdStrike UI rather than using the current method, which requires a two-factor authentication, that is something that is available to you. Just simply send us over your metadata and we can go ahead and get that configured for you. As far as APIs are concerned, if you look to leverage the CrowdStrike data anywhere outside of the solution, this is also something that you'll want to keep in mind. There are several APIs available to you. You will want to take a look at, first, understanding what information you would want to ingest outside of CrowdStrike, and where you would like to put it. Some organizations will put all of the information inside a data lake and have it for cold storage, for example. I'd say the majority of the teams will have, if they are leveraging some type of a SIM, the information that stems from our detections.
So, the areas where we have flagged alerts. And they will have that information sent to our SIM. That API, probably the most common and most frequently used by our customers, is called the Streaming API, in case you wanted to take a note of that. But again, all of the different APIs, there are several of them that are available, and they all house different pieces of information. Inside of the CrowdStrike UI, you can take a look at the documentation to better understand if that information is something that you would like to ingest elsewhere. As far as the network configuration, there are two domains over port 443 that communication is going to come down on from CrowdStrike. So, we will need a bi-directional, clear communication path from port 443 over those two domains, in order to avoid any breaks in the communication path. To expand on that, there is clear communication.
There cannot be any packet inspection present. If there is anything like SSL inspection, for example, that will be a break in the communication stream for CrowdStrike and that would cause several issues. I'd say that, generally speaking, folks that are brand-new to the product, such as the folks on the line today, if you're starting your deployment and you have some type of interference, you'll find that you will run into issues in signing into the CrowdStrike agent, if you do not have a bypass in place and you do have some type of SSL inspection, for example, at the firewall. Just make sure that you have a bypass in place.
If your firewall does not allow you to input domains, which I know some do not, we also have a listing of static IP addresses that are available, located within that Windows Deployment guide, or any of those deployment guides will list that as well. Just something to keep in mind from a network-configuration standpoint. Now, as far as the supported operating systems are concerned, Windows 7 Embedded or Windows SP1 and newer are going to be supported by CrowdStrike. Windows Server 2008 R2 and newer are supported as well. On the Mac side, we support Sierra and newer at this point, but that is something that is coming to an end of life.
Keep in mind that if you do have any Sierra products or Sierra operating system Mac machines inside of your environment, you'll want to get those upgraded. Essentially, what end of life in July means for CrowdStrike is that we will still operate completely fine for them. We will just no longer be releasing any new upgrades, or new enhancements for those machines. So, you will need to lock those machines in at a specific build of the agent in order to have CrowdStrike continue to operate on them. At the end of September, that is when CrowdStrike will fully deprecate support. It will still work, we'll still operate on those machines. We just will no longer support it. So, if you run into any issues, the solution or the response from the support organization will be that, that is no longer supported and that you need to upgrade to a newer version. And by means of that, a newer operating system as well. On the Linux front, a little bit more of a complicated animal, if you will.
There is kernel compatibility required. So, we support several flavors of Linux, but instead of one of the appendices inside of the deployment guide of Linux, you'll notice that there will be a listing of all of the kernels that are supported by CrowdStrike. Do make sure that you take a look at that if you are going to be rolling out your Linux fleet in any significant fashion. Now, a little asterisk there at the bottom. It talks through something called Reduced Functionality Mode. Now, this is something that exists both on the Windows and the Linux front. Essentially, it is a safety mechanism we have deployed, or created, to avoid blue-screening customer machines.
On the Linux and the Windows front, this exists. And since we are operating within the kernel, we are constantly looking for kernel compatibility to ensure that we can fully operate. If there is ever a kernel, or a shift in the kernel, where we do not support whatever shift that has taken place, we'll fall into this safety mode, or this reduced functionality mode, to avoid causing those types of issues. Now, I'd say the only time this really comes up on Windows is if you are very aggressive with your surrounding patching or a Patch Tuesday. A Patch Tuesday, I think was two days ago. After Patch Tuesday hits, those KBs that are released, those security updates that are released by Microsoft, are going to be a shift in the kernel. If you were to automatically update those machines, you may update faster than CrowdStrike is able to certify, saying, yes, we operate fine with those kernel versions.
You'll notice that those machines will fall into this reduced state of functionality, as it takes CrowdStrike typically 48 hours or so to certify the latest kernel or the latest versions released by Microsoft. At some point today, it's likely we will release a certification for the patches that were released by Microsoft on Tuesday. So, the ask here and the recommendation, I guess, is that you just simply hold off if you do not do so already on patching your machines until maybe the Friday after Patch Tuesday. That will give CrowdStrike three days to certify. We do release and issue out notices indicating when those certifications are present. So, that's something that you can look out for. A little bit different... just to reiterate on that, to expand. CrowdStrike essentially will have a limited amount of visibility.
It's still a lot of visibility on your machines when they're in this reduced state of functionality on Windows, but it is limited. So, do keep that in mind, that we do unhook from certain kernel aspects to avoid those types of issues. On the same note, when we do release the certification, there is no user interaction from your standpoint that you need to take in order to ensure that your machines have that certification on them. So, keep that in mind. The last thing to note is that is all specific to Windows. The same logic somewhat applies to the Linux fleet. The only difference for Linux is that when we release certification for Linux, it comes by way of an agent upgrade. So, you will need to upgrade the agent in order for that certification to be present on your machines. Secondly, when we are in that reduced state of functionality, we lose all visibility. It's not just a limited scope of visibility that is lost.
When we're in reduced functionality mode on Linux, it's essentially everything. That's the distinction and the differences between the two. Now, let's talk through some of the best practices. This is going to be more toned-in and focused on setting up things within the CrowdStrike console. The first thing that we want to talk about is something that we call "Groups". What groups are is your ability to set up collections of hosts to apply different policies to different machines. So, similar to how Active Directory has OU, where you can set up different OUs for different machines, CrowdStrike has groups where you can set up different groups to different machines. There are two different types of groups that are available to you.
There's something called a Static and a Dynamic group. Dynamic groups allow you to group up your machines based on the likeness of some type of attribute. So, things such as an operating system version, OU, site name, those items being pulled, and of course, by the Active Directory. Those are going to be some items that you can dynamically group your machines together from. Aside from that, we also have Static groups, which allow you to manually define machines, selecting them one by one, or uploading a list of those machine names into the UI. On the right here, you'll see that groups plug in to the different policies. The two that we're going to mainly focus on today are going to be the sensor update policies, as well as the prevention policies. A question that comes up quite often, I would say, especially for newcomers to the solution, is, "Well, what if I'm operating on a Windows 10 machine that I have dynamically grouped based on the operating system of Windows 10?" So, something of a pilot policy or pilot group.
On the far right, you'll see again, you move your machine into a group. You plug that group in to a certain policy. How do we delegate which policy is going to be applied to our machine when we're applied to different groups which are tied into different policies? Now, this graphic somewhat helps me explain this, and is something that you may be familiar with if you've logged into the UI, but on the far left, you have all the devices that are in your environment. As you move over a tier, all those machines will fall into the default policy until you start to create custom policies on top of that. Those custom policies are where you're going to plug in your different groups.
In my example earlier, I have a pilot policy, maybe that's plugged into Policy 1, and a dynamic policy that's going to be plugged into Policy 2. The way we delegate which of those policies is going to be applied to my machine is through something called the Order of Precedence. What this means is that whichever machine, or wherever my machine is, it's going to be applied to the policy that's highest on that list. So, in that scenario, it would fall into Policy 1. A more concrete example of this comes by way of imagining the sensor upgrades. Once you install CrowdStrike out into your environment, there's going to be a cloud mechanism that we can use and leverage to upgrade and downgrade the agents within our environment.
There's no need to do it via your deployment tool, such as SCCM or Jamf for Mac, for example. You simply just click a few buttons inside of the CrowdStrike UI, and that update will start to be delivered down through our cloud delivery system. Here on the right, you can see my recommendation for you from an update cadence. There are two different ways that you can update your machines. You can either update them in an automated fashion. So, as soon as CrowdStrike releases a new agent, it automatically plugs out and ties into all of your machines. That's one way. The other way is that you have it locked in at a specific static build number and then, as time progresses, and you're happy with the performance on maybe some subset of machines, you can push it out to the rest of the environment.
Here on the right, you'll see, I would recommend you put together some type of pilot policy that receives CrowdStrike updates in an automated fashion. That pilot policy would be a static group where you've manually selected maybe a couple dozen machines. As time progresses, and you're comfortable that none of those pilot testers are complaining or having any issues, then you would push that upgrade down to all of your workstations. Give it some additional time, push it down to the servers, and so on. This would be the mentality and the method that I would recommend you follow for the upgrades. Many organizations automatically update all of their machines.
This is just something where I take more of a cautious viewpoint to upgrading things. This is the way that I'd do it, but that's entirely up to you. Now, for the prevention capabilities. This may look like a little bit of an eye chart, so let me just break down what we're looking at here. Essentially, vertically, so each one of these rows, is going to map back to a specific prevention capability that CrowdStrike possesses within the UI. On the right side, you will see three separate phases that we would recommend you walk through as you start leveraging CrowdStrike within your environment.
The first phase being what we call a rapid deployment with a pre-existing AV. What this is, is if you have another antivirus solution, you want to take a slower approach to introducing CrowdStrike into your environment. You would want to have this initial set of toggles enabled as you deploy. And what this will allow is, this will give CrowdStrike maximum visibility into your environment without actually taking action on blocking any processes that it deems as suspicious. The reason for this is because when you introduce a new antivirus into your environment, you may find that it may block legitimate items, items that you deem as legitimate. So, if we do this in a fashion of this nature, we have the ability to gain that visibility.
If we identify it as a false positive, we can whitelist it. Then, at phase two, we can move to a heavier prevention stance, where we turn on a lot of those protection capabilities, after we've put those whitelists in place to avoid any blocking of legitimate application. Now, if you're introducing CrowdStrike into an environment that does not have a pre-existing AV, you will want to start with level number two here, the middle tier, just because this will be the settings that will have... a protection level that we would deem to adequately protect you from any of the threats that we deem as suspicious. So, this is the phase. As soon as you're comfortable with that, you would move to "Well Protected". This is a three-phased approach. The rationale for why we would take this approach, as I mentioned earlier, we want to think about if we're running side by side with an AV or not.
In this scenario, again, phase one is if we're running side by side with another AV. Phase two is if we do not have a pre-existing AV. And if we do have one, and we want to progress through these phases while still running side by side with our legacy tool, we can certainly do so. There's just going to be two toggles that we want to ensure that we keep off. Do make a note that we want to keep off the "Sensor Anti-Malware Prevention", so, in the middle of the screen, as well as the "Quarantine & Security Registration". These are the only two toggles that may not play nice with another antivirus tool present on your machines. Just go ahead and keep those disabled if you're going to look to run CrowdStrike side by side with them in a long-term fashion. Everything else should play nicely with any pre-existing AV.
The same logic applies on the prevention front for Mac. Of course, if there's a pre-existing AV on these machines, the only one that we want to keep off is going to be this "Quarantine" functionality. That gets us to the Appendix. The Appendix just reiterates some of the talking points. We talked through RFM. So, if you have more details, more questions on specifics, you can dig into the weeds at some of these different links located here. As far as best practices for deployments, we talked about creating policies. We want to get the agent deployed out there to start collecting data. As we start collecting data, we may run into items that we determine as false positives.
So, we want to monitor and triage all of these detections, whitelist the false positives, and then once we're comfortable with the noise level, we can move up to a more adequate level of protection. As far as the phased approach, this just goes into more detail about the Policy 1, Policy 2, and Policy 3, and the rationale for it. And that's going to exist both on the Windows and the Mac front, as we have mentioned. As far as the set of next steps, you'll want to make sure that we gain access to the CrowdStrike Support Portal.
On the CrowdStrike Support Portal, we will offer a bunch of support content to you. This is something where you'll want to engage with Dell Support by giving us a call. We can go ahead and get you access for your full team. We'll just need first names, last names, and emails of all the users that need access. The other thing that we'll want to understand is all of the detection email alerts. So, anytime that a detection CrowdStrike flags something as suspicious inside of an environment, we will flag a detection and an email alert will automatically be sent out to you. We'll want to know who those email contacts should be on your team that received that notice. It's pretty generic.
It just simply says "High severity alert. Here's the link, go take a look." Finally, if you are subscribed to the OverWatch service from CrowdStrike, you also will want to let us know who we should email in the event that we do identify something inside of your environment as being suspicious. So, if we identify something, a hands-on keyboard-type of intrusion, we may reach out to you. That type of scenario, would be something that, I would say, if they're reaching out to you, it's probably going to be a "priority one" type of scenario. This is why we recommend having that set up to a distribution list of some sort. That concludes the items that I had planned to share during today's onboarding webinar.