RSS Security

About FreshRSS
Before yesterdayCrowdStrike

Gem State University Saves a Small Fortune on TCO With Humio

16 September 2021 at 12:49

This blog was originally published on humio.com. Humio is a CrowdStrike Company.

Overview

The University of Idaho uses Humio to ingest and analyze network security log data at scale. Humio provides incredible cost-savings compared to their previous logging solution, helping the university increase security insights, streamline incident detection and response efforts, and reduce TCO.

“With Humio, it’s easier and faster to search than it was with previous solutions. We can get to the root of malicious activity like phishing attacks more quickly and efficiently.” — Mitch Parks, Chief Information Security Officer, University of Idaho

Challenge: Reducing Log Management Cost and Complexity

Like many budget-conscious organizations, the IT services department at the University of Idaho is always looking for creative ways to do more with less. The university was using their previous solution to capture and analyze network security log data, but the solution was costly and complicated to scale.

“Because of budget constraints, we could only afford to license 100 gigabytes of data per day. A security incident like a denial-of-service attack can easily drive up our log volumes, trigger licensing caps, and impair forensics.” — Mitch Parks, Chief Information Security Officer, University of Idaho

Solution: Humio Logs Everything at Scale in Real Time

After investigating a number of log management alternatives, including open-source solutions, the university selected Humio as its next-generation security log management platform.

“The open-source approach would have required as many as 12 servers, and we would have needed a dedicated IT person to deploy and maintain it,” recalls Parks. “That just didn’t make sense from an investment perspective. I had read about how other universities had successfully switched to Humio and decided to take a look at it.”

“We evaluated Humio for about 30 days and were quite impressed,” explains Carl Pearson, IT security analyst for the university. “The product is easy to set up and use, and doesn’t require a dedicated IT admin or a SIEM expert, or take a lot of my time to manage.”

Results: Faster and Deeper Insights, Lower TCO

Humio’s state-of-the-art log management platform helped the university improve visibility, slash operations expenses and complexity, and reduce risk and exposure.

Additional Resources

The post The Critical Role of Cybersecurity in M&A: Part 2, Pre-Close appeared first on .

Offering Our People Autonomy, Mastery and Purpose: Patrick McCormack, SVP Cloud Engineering

3 November 2020 at 18:13

When deciding to take a new job, one of the biggest concerns is often who you’ll be working for — not just the company itself, but the management and leadership team. What kind of manager will you have? Who is leading the organization from the top and what is their philosophy on learning and development? Will these people deliver all they promised during the interview phase?

In our latest installment of 5 Questions, Patrick McCormack, CrowdStrike® SVP of Cloud Engineering, talks about the three things he tries to provide every CrowdStrike engineer: autonomy, mastery and purpose.

Q: First things first, what do you look for in new candidates? Is experience in cybersecurity required?

That’s a really interesting question. CrowdStrike is a place for everyone. We have people with deep expertise in cybersecurity in areas like reverse engineering or writing detection algorithms, but actually, a lot of the work, particularly as it relates to the cloud and our sensor, is deep software engineering that is not concerned with security.

I didn’t have a particularly strong security background when I joined. But I brought a lot of knowledge and experience in building large-scale distributed systems in the cloud. So when we’re looking at hiring engineers — whether they are UI platform devs, cloud development engineers or kernel engineers working on the sensor side — they don’t necessarily have to know anything about security. I think this is an important point because engineers can be put off because they think they need to know about security to apply for positions at CrowdStrike, but for the most part, we are looking for world-class engineers regardless of their cybersecurity background.

Q: A lot of engineers might not be familiar with CrowdStrike. Why should they be interested in our company?

The thing I like most about working here is knowing that we’re protecting our customers. I’ve seen situations where we’ve had alerts go off late in the afternoon because we’re seeing a huge influx of detections from a particular customer. We realize that the customer has been targeted via email and people are clicking on malicious attachments. We’re registering all of those detections, but we can see that there’s nobody in the company that’s noticing, apart from their SOC (security operations center). The average user might be sending emails on a laptop as usual, and not even know that we’re at work protecting them from all this bad stuff that’s trying to run on the machine. That’s huge for me.

From a technology point of view, what we do here is incredible. We have kernel-level developers working on our sensor, we run a hybrid cloud backend over 4 geographic regions worldwide and we are architected to be up 24×7 with zero downtime. If you are interested in working at the kernel or OS level, or on massive async event-driven distributed systems, or on a state of the art UI and you also want your work to be important and impactful, then this is the place for you.

Q: So tell me a little more about the culture. What’s it like to work for CrowdStrike?

Culture is very important to us. Our internal mantra is “one team, one fight” and we live that every day. We foster a high-trust and high-autonomy work environment. We have a high bar for new hires so we don’t want to bring smart engineers on board and  tell them “Okay, sit there and I’ll tell you exactly what to do.” We want them to tell us what to do. We encourage a free and open exchange of ideas and it does not matter if you are an intern or a senior engineer with 20 years of experience. A healthy organization is one where anyone can approach the leadership team or their teammates and say, “Hey, I see you guys are doing something in a particular way. I’ve developed a system like that in the past and I think I can improve on what you are doing; let me tell you about it.” Everyone’s voice and opinion matters — we’re stronger because of our diversity of opinions and ideas.

There’s a refinement of self-determination theory that says that there are three things people want from every job: autonomy, mastery and purpose. This is something that as a leader I consciously think about, as we are scaling up the engineering organization. We try to give our engineers autonomy in their work so they take pride in what they do because they own their work.

We also keep people learning, which is the mastery part. I always want to be stretched in different directions, whether it’s technically — taking on new areas, looking at new ways of doing things or adopting new technology — or from a management and leadership position. I think most engineers, most people in fact, feel the same way.

Finally, there’s purpose, which we’ve talked about a bit already. I think that’s the one thing that everyone here really loves. We have a strong sense of purpose. We’re not trying to get people to tweet at each other or target people with ads—we’re protecting our customers and making the world a safer place. That may seem like hyperbole, but we protect computers in hospitals and if a doctor can’t access a sick patient’s records because of ransomware, that’s a very serious situation. Our engineers get a huge sense of satisfaction that we’re doing something that has a very strong sense of purpose.

Q: Tell me a little more about being a platform-based company. What do you and your team do day-to-day?

The platform group builds and operates “platform-as-a-service” (PaaS), which is used by product groups who are building customer-facing products. We build for scale and reliability and we cover everything from the sensor to cloud ingestion, data processing pipelines, services and libraries for building sensors and user interfaces. We don’t want each one of these product groups to have to figure out how to build and deploy cloud services on their own or how to scale them or make them robust. We provide that platform for them to plug into, and they can focus really on the business logic of what they’re building. Also, just to give you an idea of the scale we operate at, the cloud ingests and processes in near real time over four trillion security events a week.

I oversee both the tactical and strategic aspects of platform development and operations. Tactical means everything from running and operating our cloud product across the world, 24×7, at scale. This also means planning and executing on the delivery of new platform features over the next three to six months. When we look six months and beyond we are thinking about the new capabilities we need to build and also about existing systems that need to be revved to handle our growth. You always have to be thinking about the future because at our scale you can’t wait for an inflection point to start developing; by that time it’s too late and you’ll have hit a hard scaling limit.

Q: What do you like to do for fun outside of work?

Mostly hiking and reading. In fact, right now I’m in the middle of The Undoing Project by Michael Lewis. The Undoing Project is super interesting because it’s about how people make decisions and common errors in decision-making. In addition, I am reading a book about Roland Barthes, as well as Practical TLA+ .

Are you interested in working on Patrick’s team at CrowdStrike? Head to our Resource & Engagement Portal at GopherCon 2020 where you can find out how to meet our team and talk all things cyber: https://www.gophercon.com/page/1623781/crowdstrike

Not attending GopherCon? check out the CrowdStrike Careers page to learn more about our teams, our culture and current open positions.

Additional Resources:

The post Offering Our People Autonomy, Mastery and Purpose: Patrick McCormack, SVP Cloud Engineering appeared first on .

Seeing Malware Through the Eyes of a Convolutional Neural Network

3 November 2020 at 17:36

Motivation

Deep learning models have been considered “black boxes” in the past, due to the lack of interpretability they were presented with. However, in the last few years, there has been a great deal of work toward visualizing how decisions are made in neural networks. These efforts are saluted, as one of their goals is to strengthen people’s confidence in the deep-learning-based solutions proposed for various use cases. Deep learning for malware detection is no exception here. The target is to obtain visual explanations of the decision-making — put another way, we are interested in the highlights that the model makes in the input as having potential malicious outcomes. Being able to explain these highlights from a threat analyst’s point of view gives a confirmation that we are on the right path with that model. We need to have the confidence that what we are building does not take completely random decisions (and get lucky most of the time), but rather that it has the right criteria for the required discrimination. With proof that the appropriate, distinctive features between malware and clean files are primarily considered during decision-making, we are going to be more inclined to give the model a chance at deployment and further improvements based on the results it has “in the wild.”

Context

With visualizations we want to confirm that a given neural network is activating around the proper features. If this is not the case, it means that it hasn’t learned properly the underlying patterns in the given dataset, and the model is not ready for deployment. A potential reaction, if the visualizations indicate errors in the selection of discriminative features, is to collect additional data and revisit the training procedure used.

This blog focuses on convolutional neural networks (CNNs) — a powerful deep learning architecture with many applications in computer vision (CV), and in recent years also used successfully in various natural language processing (NLP) tasks. To be more specific, CNNs operating at the character level (CharCNNs) are the subject of visualizations considered throughout this article. You can read more about the motivation behind using CharCNNs in CrowdStrike’s fight against malware in this blog, “CharCNNs and PowerShell Scripts: Yet Another Fight Against Malware.” The use case is the same in the upcoming analysis: detecting malicious PowerShell scripts based on their contents, with a different target this time aimed at interpretability. The goal is to see through the eyes of our model and to validate the criteria on which its decisions are based.

One important property of convolutional layers is the retention of spatial information, which is lost in the upcoming fully connected layers. In CV, a number of works have asserted that deeper layers tend to capture more and more high-level visual information. This is why we use the last convolutional layer to obtain high-level semantics that are class-specific (i.e., malware is of interest in our case) with the spatial localization in the given input. Other verifications in our implementation are aimed at reducing the number of unclear explanations due to low model accuracy or text ambiguity. To address this, we take only the samples that are correctly classified, with a confidence level above a given decision threshold of 0.999.

Related Work

Among the groundbreaking discoveries leading to the current developments in CNN visualizations, there is proof (Zhou et al., 2015a) that the convolutional units in the CNNs for CV, act as object detectors without having any supervision on the objects’ location. This is also true in NLP use-cases, as the localization of meaningful words discriminative of a given class is possible in a similar way. Among the initial efforts towards CNN visualizations we can also mention the deconvolutional networks used by Zeiler and Fergus (2014) to visualize what patterns activate each unit. Mahendran and Vedaldi (2015) and Dosovitskiy and Brox (2015) show what information is being preserved in the deep features without highlighting the relative importance of this information.

Zhou et al, 2015b propose CAM (class activation mappings) — a method based on global average pooling (GAP), which enables the highlighting of discriminative image regions used by the CNN to identify a given category. The direct applicability is in CV, as it is the case with most of the research done in this respect. However, it should be mentioned, once again, that the use cases extend to NLP as well, with a few modifications in the interpretations.

CAM has the disadvantage of not being applicable to architectures that have multiple fully connected layers before the output layer. Thus, in order to use this method for such networks, the dense layers need to be replaced with convolutional layers and the network re-trained. This is not the case with Grad-CAM (Selvaraju et al., 2016), Gradient-weighted CAM, where class-specific gradient information is used to localize important regions in the input. This is important as we want a visual explanation to be first, class-discriminative, meaning we want it to highlight the features (words/characters/n-grams) that are the most predictive of a class of interest which, in our case, would be malware.

Grad-CAM

Figure 1 offers a high-level view of how Grad-CAM is applied to textual inputs. Particularly, our interest is to visualize malicious PowerShell content in a heatmap fashion. In these visualizations, the most predictive features for malware are highlighted with different intensities according to their weights, from the perspective of our convolutional model. The following elements and actions are applicable in the mentioned Grad-CAM flow:

Figure 1: High-level view on the applicability of Grad-CAM for textual inputs. The more specific use-case hinted to in the diagram is heat map visualizations for malicious PowerShell scripts. (click image to enlarge)

• Inputs — in the current use-case the inputs provided are PowerShell scripts contents and the category of interest, which is malware in our case.
• Forward pass is necessary as we need to propagate the inputs through the model in order to obtain the raw class scores before softmax.
• Gradients are set to 0 for clean and 1 for malware (the class that is targeted).
• Backpropagate the signals obtained from the forward pass to the rectified convolutional feature map of interest, which is actually the coarse Grad-CAM localization.
• GradCAM outputs, in our case, are visualizations of the original scripts, with the most predictive features for the given class highlighted.

In Grad-CAM we try to reverse the learning process in order to be able to interpret the model. This is possible using a technique called gradient ascent. Instead of the regular weighted delta updates that are done to reduce the loss gradient x (-1) x lr, in gradient ascent, more delta is added to the area to be visualized in order to highlight the features of interest.

The importance of the k-th feature map for target class c is determined by performing Global Average Pooling (GAP) in the gradient of the k-th feature map:

$\alpha_k^c = \overbrace{\frac{1}{Z} \sum_{i}\sum_{j}}^{global\; average\; pooling} \underbrace{\frac{\delta y^{c}}{\delta A_{ij}^{k}}}_{gradients\; via\; backprop}$

where

$$A_k \in \mathbb{R} ^ {u \times v}$$ is the k-th feature map produced by the last convolutional layer, of width u and height v.
$$y ^ c$$ — any differentiable activation (not only class scores), which is why Grad-CAM works no matter what convolutional architecture is used.

Global-average-pooling is applied on the gradients computed:

$\frac{\delta y^{c}}{\delta A_{ij}^{k}}$

Thus, we obtain the weights $$\alpha_k^c$$, which represent a partial linearization of the deep network downstream from A and capture the importance of feature map k for a target class c.

Then we take the weighted average of the activation for each feature map. In order to do this, we multiply the importance of the k-th feature map:

$L_{Grad-CAM}^{c} = ReLU \underbrace{\left(\sum_{k}{\alpha_k^c}{A^k}\right)}_{linear\; combination}$
$$L_{Grad-CAM}^{c}$$ class discriminative localization map, which is a weighted combination of the feature maps, followed by ReLU.

In our experiments, the following steps apply at the implementation level:

1. Automatically find the last convolutional layer in the network. Generally, the feature maps in the last convolutional layers tend to have the best compromise between high-level semantics and detailed spatial information. This is precisely the reason why we also use it in this process. In Tensorflow, which is the framework used in our experiments, we can identify various types of layers by their names. For our architecture in particular, we can iterate through the layers in reverse order and determine the first layer with a three-dimensional output, which is actually our last 1D convoluted layer.

Figure 2: Heatmap visualizations of clean (left) and malicious (right) PowerShell files, resulted from GradCAM.

2. We build a gradient model by providing:

a. Inputs: the same as the inputs to the pre-trained CharCNN model
b. Outputs:

i.The output to the final convolutional layer (previously determined) of the network
ii. The output of the softmax activations from the model

3. In order to compute the gradient of the class output w.r.t. the feature map, we use GradientTape for automatic differentiation.
4. We pass the current sample through the gradient model and grab the predictions as well as the convolutional outputs.
5. Process the convolutional outputs such that they can be used in further computations (i.e., discard the batch dimension, evaluate the tensors, convert to numpy arrays if necessary, etc.).
6. Average the feature maps obtained and normalize between 0 and 1.

The result of all of the processes described above is a heatmap visualization for the class label of interest (i.e., malware in our case). We scale this heatmap and use it to check out where the CNN is “looking” in the input to make that classification. Examples of heatmap visualizations for both the clean and malicious PowerShell inputs are displayed in Figure 2. The left heatmap represents a clean file, with different nuances of blue for different substrings, where deeper blue is correlated with the most predictive features for clean scripts. On the right, we have a similar interpretation for malware. A darker assigned color means that the corresponding substring is more likely describing suspicious activity.

Most Predictive Features

In order to justify the class-discrimination capabilities of our PowerShell model, we produce visualizations for both malware and clean samples, with a focus on the class of interest — malware. We consult with our threat analysts and conclude that many of the substrings highlighted in the samples are actually of interest in classifying maliciousness in scripts. Through this section, we are often going to refer to these highlights as substring matches.

A strict selection is performed on all of the generated substring matches. These are checked against our Malquery database, with zero tolerance for false positives. Later, the substrings in the selected subset are considered for additional support to our PowerShell detection capabilities. The following sections briefly introduce three of the broadest categories of important substrings for our model in deciding the maliciousness of PowerShell scripts.

Base64 Strings

Substring 1: piJ0DAIB9EAB0seuZZotF3GaJh4gAAADrtmaLReBmiYeKAAAA665Vi+yhtGdMAItNGIP4AQ+FwZ4DAItFCIP4

Click image to enlarge.

Many of the substring matches generated are Base64 strings, which are eventually converted to byte code. Take, for example, Substring 1, a Base64 string that also shows up in a malicious script (i.e., out-2112577385.ps1) on a page full of exploits. This string, of particular importance for our model in detecting malware in the given PowerShell content, is a tiny part of a huge Base64 string made out of many smaller pieces. The mentioned full string decodes into the hexdump of a Portable Executable (PE) file, which is a malicious AutoIt compiled file. Among the elements identified in the mentioned PE code, we can count intercepting both asynchronous and synchronous keyboard presses, the ability to send and receive files, as well as some other nested Base64 encoded PE content.

Common Syntax

Substring 2: IEX (New-Object IO.StreamReader(New-Object

Click image to enlarge.

Substring 3: IO.Compression.CompressionMode]::Decompress))).ReadToEnd()))

Click image to enlarge.

The opposite of Base64 strings, in terms of readability, is common PowerShell syntax, which is also included in the patterns generated. In this category we have substrings from comments, invokes that are not necessarily indicators for dirty scripts, download paths/upload links, etc. These are, in general, not a safe bet for standalone use in malware hunts. This is one of the reasons why we double-check the ML (machine learning)-picked substring matches against our database and remove the ones that give even one false positive. However, some of this regular PowerShell syntax keeps showing up in the set of selected patterns. Substring 2 is a good example, representing a part of a decoding sequence for Base64 strings. This type of encoding is a common practice used by attackers to evade simple detection techniques (e.g., regex, heuristic approaches). The last part of said decoding syntax also shows up as one of the ML-selected patterns of interest here — see Substring 3. Perhaps surprisingly, again, Substring 3 shows up in 93 malicious scripts in an exact Malquery search, and in no files tagged as clean. However, this is still common syntax that in and of itself has nothing to do with malware.

Nonetheless, our interpretation is that it is more likely that we will see this syntax in malicious code rather than in clean scripts, as we’ve rarely encountered benign PowerShell with Base64 strings and their almost immediate decoding.

Another substring match that is not part of a Base64 string is Substring 4, which, according to the PowerShell documentation, is short for running a PowerShell command in hidden window style. It is perhaps implied that this substring match might also show up in clean PowerShell scripts as part of some benign automation. However, from our validation, this substring search in Malquery only hits tagged dirty files, if we do not consider the 318 hits with unknown labels. Thus, this is an example of a pattern that will be subject to further validation in staging.

Substring 4: powershell /w 1 /C

Click image to enlarge.

Common Obfuscation

Obfuscation techniques for Windows Portable Executables are also detected as significant strings in our model. It is clear why attackers would try to obfuscate other executions launching from within the current script. Two such examples selected from our set of potential templates are Substring 5 and Substring 6Substring 5: Chr(Asc("x")) + Chr(Asc(“e”))

Click image to enlarge.

Substring 6: Chr(101) & "xe';"

Click image to enlarge.

Conclusion

In this blog we introduced a visualization technique that exploits the explainability potential of convolutional neural networks. The context, motivation and importance of seeking interpretability in our models were also discussed. We briefly described the components and flow in a visualization technique coming from the computer vision domain, namely Grad-CAM. By employing this technique with additional filtering, we can obtain a set of malware predictive substrings that further complement our current detection capabilities for PowerShell scripts. A few examples of such substrings are discussed at length in this article.

Additional Resources

The post Seeing Malware Through the Eyes of a Convolutional Neural Network appeared first on .

How to Enable Kernel Exploit Prevention

30 October 2020 at 18:34

Introduction

This document and video will demonstrate how to enable kernel exploit prevention to protect hosts from sophisticated attacks that attempt kernel code execution.

Overview

Malware, and in particular ransomware, is increasingly using sophisticated attack chains to bypass traditional AV and execute successfully. As an example, the Robinhood ransomware was updated to load and exploit a legitimately signed driver as a mechanism to achieve kernel code execution. With a lot of endpoint solutions, the malware can execute and successfully encrypt the file system because the driver appears to be legitimate.

Even with a detection only policy, execution of the Robinhood ransomware triggers multiple CrowdStrike detections as shown below. While machine learning correctly identifies the ransomware, Falcon also detects data encryption as well as kernel level defense evasion.

Enabling Kernel Exploit Prevention

To prevent this type of attack, a simple policy change is required. Along with machine learning and behavioral based protections, CrowdStrike can also block executions by category. For this attack, enabling the prevention of  “Suspicious Kernel Drivers” will ensure that any driver found to be malicious by CrowdStrike will be blocked from loading.

Kernel Exploit Protection

With prevention enabled, the attack fails and the files are not encrypted. The execution details illustrate that CrowdStrike blocked the operation to start a malicious driver. The critical severity detection includes the tactic, technique and ID, as well as the triggering indicator of attack and a written description.

Closing

While the use of legitimate drivers might bypass traditional anti virus, CrowdStrike’s easy to configure prevention capabilities enable detection of malicious drivers and protect organizations against sophisticated attacks.

More resources

The post How to Enable Kernel Exploit Prevention appeared first on .

How to Consume Threat Feeds

30 October 2020 at 07:00

Introduction

As part of the CrowdStrike API, the “Custom IOC APIs” allows you to retrieve, upload, update, search, and delete custom Indicators of Compromise (IOCs) that you want CrowdStrike to identify.

With the ability to upload IOCs to the endpoints can automatically detect and prevent attacks identified by the indicators provided from a threat feed.

Prerequisites

To get started with the CrowdStrike API, you’ll want to first define the API client and set its scope. Refer to this guide to getting access to the CrowdStrike API for setting up a new API client key. For the new API client, make sure the scope includes read and write access for IOCs (Indicators of Compromise).

As example IOCs, we will be using the test domain “evil-domain.com” and the file “this_does_nothing.exe” (this_does_nothing.exe (zipped), Source Code (zipped), which has a sha256 hash value of 4e106c973f28acfc4461caec3179319e784afa9cd939e3eda41ee7426e60989f .

Beginning with the Crowdstrike API

CrowdStrike leverages Swagger to provide documentation, reference information, and a simple interface to try out the API.

Before accessing the Swagger UI, make sure that you’re already logged into the Falcon Console.

Here’s a link to CrowdStrike’s Swagger UI.  Authorize with your Client ID and Client Secret that’s associated with the IOC scope as shown in the guide to getting access to the CrowdStrike API.

After you’re authorized, find the IOCs resource on the page. These are going to be the requests that we’ll demonstrate in this guide.

Creating an IOC

First, let’s create a couple of new IOCs. We will add an IOC for the domain “evil-domain.com” and the file hash “4e106c973f28acfc4461caec3179319e784afa9cd939e3eda41ee7426e60989f” from our sample file.

Click on POST /indicators/entities/iocs/v1 to expand it. This will provide you with descriptions of the parameters and how you can use them. It also shows sample responses below as well.

The information provided here is great at helping you understand how to issue the requests and is all very interesting, but we can actually take it to the next step by making a request directly from the interface with the “Try it out” button. This guides you on how to implement the CrowdStrike API and allows you to test requests directly while having the documentation readily available.

Click on “Try it out”.

The “Try it out” button will make the Example Value box editable. It is prepopulated with placeholder values which we will replace in just a moment. We can see that even though there are several keys that we can modify, the only required ones are type, value, and policy. We’ll use the required keys for now and just enter the necessary values that we need to create the IOCs.

We can create an individual IOC or multiple IOCs in a single request, so we’re going to add both sample IOCs with our single request. You can edit your Example Values manually or just replace the existing contests with the following:

[
{
"policy": "detect",
"type":"sha256",
"value":"4e106c973f28acfc4461caec3179319e784afa9cd939e3eda41ee7426e60989f"
},
{
"policy": "detect",
"type":"domain",
"value":"evil-domain.com"
}
]

Hit the “Execute” button at the bottom and you can see your response body below.

If everything went as expected, you will receive a “200” under Code and no “errors” in the body of the response. If you receive a “401” error and see “access denied” in the body of the message, double check your authorization.

Note: The actual curl command will include authorization information that is not shown here.

Listing IOCs

Now that we’ve created a few IOCs in the CrowdStrike Platform, let’s list them out. Click on GET /indicators/queries/iocs/v1 to expand it.

Again, it’ll provide you with a description of the available parameters and how to use them. Now, click on the “Try it out” button.

Something that you might notice right away is that instead of a single Example Value box, the IOC search resource provides a series of fields where you can enter values in directly.

For example, you can enter “sha256” into the “types” box and then hit “Execute”.

After we execute the request, it will pull up the sha256 hash of the IOC that we created earlier and list it in the details section below. CrowdStrike provides many other parameters that you can use to perform your searches. For example, you can narrow down your search to only IOCs created after a specified time or for specific hash values. Take a look at the other fields to see what else you can do.

An example detection from an imported IOC

To demonstrate what a detection based on your custom IOC looks like, we will use a Windows machine with CrowdStrike Falcon installed.
You can run our test tool “this_does_nothing.exe” (see beginning of article) and verify in the command window that opens, that the sha256 hash matches the IOC we uploaded.

Immediately after you execute the test tool, you will see a detection in the Falcon UI.

Deleting an IOC

So far, we’ve created a few IOCs and searched for them. Now, let’s use the Delete request to remove IOCs that we no longer want detected.

Click on DELETE /indicators/entities/iocs/v1 to expand it. Since deleting an IOC is a very straight forward process, there are only two parameters available here, just the type and value, both of which are required.

Click on the “Try it out” button.

The Delete resource also provides fields that you can fill in. We’ll enter the same sha256 value where the type is “sha256” and the value is “4e106c973f28acfc4461caec3179319e784afa9cd939e3eda41ee7426e60989f”. Just enter those values into the fields and hit the “Execute” button.

Now let’s verify that we have deleted the file hash by executing the Search IOC request again.

Expand the GET /indicators/queries/iocs/v1 again and this time, let’s leave all the fields blank. Since none of the fields are required, this will search through all the IOCs in our CrowdStrike environment.

When we receive the response, we can see that the only IOC still listed is the domain.

You can now delete the evil-domain.com with the delete request as well.

Conclusion

This guide is just the start of your journey with the CrowdStrike API. There is plenty of additional information in the CrowdStrike API Swagger UI, as well as in the Custom IOC APIs Documentation accessible through the Falcon console Docs menu.

More resources

The post How to Consume Threat Feeds appeared first on .

How to Integrate with your SIEM

30 October 2020 at 07:00

Introduction

The Falcon SIEM Connector provides users a turnkey, SIEM-consumable data stream. The Falcon SIEM Connector:

• Transforms Crowdstrike API data into a format that a SIEM can consume
• Maintains the connection to the CrowdStrike Event Streaming API and your SIEM
• Manages the data-stream pointer to prevent data loss

Prerequisites

Before using the Falcon SIEM Connector, you’ll want to first define the API client and set its scope. Refer to this guide to getting access to the CrowdStrike API for setting up a new API client key. For the new API client, make sure the scope includes read access for Event streams.

The CrowdStrike Falcon SIEM Connector (SIEM Connector) runs as a service on a local Linux server.

The resource requirements (CPU/Memory/Hard drive) are minimal and the system can be a VM.

• Supported OS (64-bit only):
• CentOS/RHEL 6.x-7.x
• Ubuntu 14.x
• Ubuntu 16.04
• Ubuntu 18.04
• Connectivity: Internet connectivity and ability to connect the CrowdStrike Cloud (HTTPS/TCP 443)
• Authorization: Crowdstrike API Event Streaming scope access
• Time: The date and time on the host running the Falcon SIEM Connector must be current (NTP is recommended)

Installation and Configuration

To get started, you need to download the rpm install packages for the SIEM Connector from the CrowdStrike Falcon UI.

For a more comprehensive guide, please visit the SIEM Connector Feature Guide.

Download the package for your operating system to the Linux server you’d like to use.

Open a terminal and run the installation command where <installer package> is the installer that you had downloaded :

• CentOS:
sudo rpm -Uvh <installer package>
• Ubuntu:
sudo dpkg -i <installer package>

The last step before starting the SIEM Connector is to pick a configuration. There are a couple of decisions to make. The SIEM connector can:

• Output to a local file (your SIEM or other tools would have to actively read from that file)
• Output to a syslog server (most modern SIEMs have a build in syslog receiver)
• Output to a format such as CEF or LEEF for your SIEM

Here is a flow diagram of how to pick the right configuration file:

To get you started, we’ll use the default output to a JSON file and only change the Client ID and Client Secret. Since we’re just going to be testing with a single SIEM Connector, the app_id can stay as the default.

Open the SIEM Connector config file with sudo and your favorite editor and change the client_id and client_secret options:

/opt/crowdstrike/etc/cs.falconhoseclient.cfg

Once you save the configuration file you can start the SIEM connector service with one of the following commands:

• CentOS:
sudo service cs.falconhoseclientd start
• Ubuntu 14.x:
sudo start cs.falconhoseclientd
• Ubuntu 16.04 and later:
sudo systemctl start cs.falconhoseclientd.service

To verify that your setup was correct and your connectivity has been established, you can check the log file with the following command:

tail -f /var/log/crowdstrike/falconhoseclient/cs.falconhoseclient.log

You should see a Heartbeat. If you see an error message that mentions the access token, double check your Crowdstrike API Client ID and Secret.

Conclusion

The process above shows how to get started with the CrowdStrike Falcon SIEM Connector. There are many more options for this connector (using a proxy to reach the streaming API, custom log formats and syslog configurations, etc.) that can be found in the “SIEM Connector Feature Guide” as part of the Documentation package in the Falcon UI.

More resources

The post How to Integrate with your SIEM appeared first on .

New Podcast Series: The Importance of Cyber Threat Intelligence in Cybersecurity

29 October 2020 at 00:01

A new CrowdStrike® podcast series hosted by Cybercrime Magazine focuses on the critical role cyber threat intelligence (CTI) plays in an effective cybersecurity strategy. The series features CrowdStrike SVP of Intelligence Adam Meyers, a renowned expert in the field of cyber intelligence and a highly sought-after speaker. In this 12-part series, Meyers will cover a wide array of CTI topics ranging from how to build an effective threat intelligence practice to how adversaries and the threat landscape are evolving and what organizations can do to better protect themselves.

Here’s the podcast lineup and quick summary of each episode. Put them on your list!

Getting to Know Adam Meyers

Meyers has long been considered a leading expert in the field of threat intelligence. In this first podcast to launch the series, he explains how his wide-ranging interests — from political science to epidemiology to computer science — and his work in both government and commercial organizations have contributed to his passion for and expertise in CTI. You’ll hear about the team of unmatched intelligence experts Meyers has built at CrowdStrike and how his team has evolved. He began with a mission to build government-quality intelligence for the private sector, focusing on nation-state adversaries, and the team soon evolved into tracking eCrime, hacktivism and recently, COVID-19-themed attacks.

Outpacing Your Adversaries

Meyers discusses the importance of knowing the capabilities and intentions of cyber adversaries that are targeting your organization and industry. He stresses that staying ahead of today’s ever-evolving adversary groups is critical and can’t be accomplished without effective CTI. Ultimately, understanding as much as possible about the “who, what and how” of your attacker is key. Meyers says, “I think about trying to bring the right components of technology and the right information together to ensure that you can, if not prevent, then certainly very quickly detect an adversary as they make attempts to access your infrastructure.”

Why CTI Is Critical to the C-Suite

Meyers discusses the importance of keeping C-level executives and board members apprised of security and risk issues and offers recommendations on the best way to present CTI to them. He recommends starting with basic information that enables them to understand what’s going on and how it may impact the organization. He explains the importance of understanding what the C-suite wants to gain from the discussion. You must first ask, “Who is your audience? Who are you bringing this intelligence to, and what is your expected outcome? Because you need to really understand what they are hoping to get out of this information.” He feels this is particularly critical because many organizations try to figure out their return on investment for threat intelligence before they have defined what threat intelligence is to them and what their measurements of success are.

How CTI Helps Security Operations Center (SOC) Teams and Incident Response (IR)

The benefits that CTI offers to SOC and IR teams start with intelligence automation, which makes their jobs easier. Meyers discusses the importance of offering context and analysis to threats, giving teams a better perspective and understanding of each threat and its potential capabilities. Meyers believes that CTI can be particularly beneficial to investigations being conducted in real time: “If they’re dealing with an active incident where the adversary is still there, understanding how to properly mitigate that incident so as not to cause the adversary to do something that would be unexpected or perhaps disruptive or destructive is critical. It’s really a very important part of the IR side of things.”

The CTI Lifecycle

Meyers discusses the need for security teams to better understand the business questions the C-suite is asking so they can better protect the organization. Meyers talks about how applying the intelligence lifecycle helps organizations answer these questions  by providing a framework for the collection, analysis and dissemination of impactful threat intelligence to leadership.  Meyers underscores the importance of decision makers to provide feedback to the team in order to help them keep pace with evolving business and risk reduction strategies.

Business Drivers

Many organizations begin implementing threat intelligence when their security teams find themselves addressing the same problem over and over, and when leadership stumps them with questions about the latest threats they may see in the news. Meyers discusses the prerequisites to implementing a successful threat intelligence program and how to find, recruit and retain skilled intelligence analysts.

Team Members

Meyers discusses the importance of building cyber threat intelligence teams with a focus on both technical and human analysis. He explains that a technical staff is required to derive intelligence by examining an adversary’s malware, tools and infrastructure.  Meyers further states that human analysts are critical, as they add an understanding of the adversaries intentions enhanced by experience that allows them to make estimations about what may happen in the future.

Hostile Nations

In this episode, Meyers examines Chinese, Russian, North Korean and Iranian cyber operations.  He breaks down nation-state activity by discussing diplomatic, political, military, and economic espionage as well as describing disruptive/destructive offensive cyber operations.  Meyers also delves into how North Korea uses financially motivated attacks and how these nation states cooperate to meet mutually beneficial objectives.

Asia-Pac and Japan

Meyers discusses CrowdStrike’s Asia Pacific/Japan State of Security Survey with a special emphasis on how COVID-19 has shaped organizations’ digital and work-from-home strategies.
He describes how adversaries are preying on the fear and disruption caused by the coronavirus pandemic and how the rapid pivot of organizations to work-from-home has created opportunities for adversaries to probe for security gaps in the newly deployed infrastructure.

Who Are Hacktivists?

Meyers explores how activists, nationalists, terrorists and socio-economically motivated groups leverage DDOS attacks, doxxing and web defacement to express their ideologies. He states “Hacktivists movements around the globe are constantly changing and very dynamic, but any place you see any sort of social or political or economic issue you can expect to find it”.  Meyers recommends steps CISOs should take to be prepared and aware of these unexpected events.

For Manufacturing

In the first six months of 2020, the CrowdStrike Falcon OverWatchTM team has tracked more intrusions than what they have seen in all of 2019.  Meyers discusses the acceleration of these attacks and how adversaries are joining the growing trend of targeted, low-volume/high-return ransomware deployment known as “big game hunting.”

For G2000 CISOs

Meyers discusses how the global threat landscape changed due to COVID-19 and how the rapid pivot of organizations to work-from-home has created opportunities for adversaries to probe for security gaps in the newly deployed infrastructure.  He predicts a continued acceleration in threat levels — attempted intrusions, ransomware attacks and other malicious activities — and discusses how CrowdStrike is helping organizations innovate and evolve faster than the adversary.

Additional Resources

The post New Podcast Series: The Importance of Cyber Threat Intelligence in Cybersecurity appeared first on .