At Chuco, we work with Tanium customers and partners daily to ensure cyber security is a top priority. Through years of endpoint security experience, we’ve developed a deep understanding of what it takes to make organizations successful with Tanium endpoint products.
This white paper presents useful and proven tips we recommend to improve endpoint security operations in your organization with Tanium.
Enter Your Email to Download the White Paper:
The FTC means business when it comes to pushing organizations to patch Log4j promptly. On January 4, 2022, the FTC blog issued a reminder that failure to mitigate known software vulnerabilities could result in legal action. The FTC highlighted the $700 million fine issued to Equifax for its failure to patch a known vulnerability – which resulted in exposing the personal information of 147 million consumers – as proof that they are holding businesses accountable for security.
In addition to the punitive and legal risks faced from the Log4j vulnerability, there is clear evidence that threat actors, including known nation-state actors and cybercrime organizations, have moved quickly to exploit “Log4Shell.” The exploit makes it simple to execute malicious code remotely, and is estimated to affect hundreds of millions of devices. In parallel, enterprises, vendors and cloud services have moved to patch their systems fairly swiftly. But given its pervasiveness, finding every single instance of Log4j in every environment could take years. And every day a vulnerable device goes unpatched is another day that an attacker could compromise a system, install a backdoor, and quietly wait to attack.
Even if you’ve taken the initial steps to patch your systems, the problem is that Log4Shell is not your typical vulnerability. Log4j is not software from a single vendor. The Apache Log4j software library is an open-source building block used widely across millions of web sites and cloud applications you use, adapted in different ways. It’s also used in a range of operational tools, equipment and devices you may never have imagined were running so much code. In some instances, it’s even repackaged, renamed, and/or embedded into the application itself – so deeply buried that it is difficult to find.
Finding which assets across your environment need to be updated is challenging. Many endpoint tools can’t scan all your workloads at scale or provide accurate answers about what’s running on your network quickly enough. When it comes to addressing your cyber security challenges, the Tanium platform has an advantage with speed and accuracy, and delivers valuable endpoint visibility and control using a combination of tools:
In addition to the tools and technology, the Tanium User Community is where you can engage with industry peers and other security experts to get technical guidance on Tanium products. Contributors from the Tanium community provide insights and updates on major threats and have been a valuable resource for technical details on the Log4Shell vulnerability.
At Chuco, we’ve already been helping many of our clients – from large enterprises to smaller organizations – in finding, patching and remediating Log4j vulnerabilities. Our Tanium Consultants, many of whom have previously worked at Tanium and/or on enterprise SecOps teams, are all Tanium Certified and can help with getting the most out of Tanium to address your needs.
Please get in touch to discuss how Chuco can help you with Log4j mitigation. Our consultants are standing by to help design or extend your response strategy, and put hands on keyboard to help execute.
Alert fatigue is a well known problem in cybersecurity. Many organizations are flooded with so many security notifications, they are at significant risk of missing actual threats.
Tanium Threat Response gives organization threat hunting, security operations, and incident response teams the deep visibility to surface valuable security endpoint data and telemetry. Events are generated, providing security teams with various insights into their environment, including risky behavior, suspicious usage, vulnerabilities, misconfigured settings, as well as serious indications of compromise. A client with no previous visibility on enterprise-wide endpoint security data may be overwhelmed with the thousands of new insights they receive from Tanium.
Recently, Chuco helped a client reduce the volume of security events they were receiving from Tanium Threat Response. The client, a large business unit within one of the world’s largest multinational corporations, had been receiving over 10,000 event alerts a day.
The good news is that you can tune your security events to dial down the “noise” and make it easier to identify relevant threats. We helped our client reduce the number of events to between 10 and 50 a day by filtering out benign behaviors and low priority items.
How did we do it? We followed a multi-phase iterative method to test and tune the types of alerts the client was receiving from Tanium.
The Tanium Event Recorder collects very valuable data – every process, every file change, and every modification on the system is captured. Tanium Signals then applies intelligence to let you know when anomalies happen, so you can investigate for possible attacks, breaches, misconfigurations and other vulnerabilities. The challenge for IT and security teams is to prepare so that they aren’t immediately overwhelmed by the alerts that are generated.
Creating a test environment to confirm that the intelligence is useful is the best way to start. It gives you a chance to identify any benign behavior in your environment that may initially trigger false positives. For example, there may be actions your sysadmins perform periodically which should be filtered out.
Many clients have asked whether AI and machine learning can be used to separate the signals from the noise. While much progress has been made in applying machine learning to identify potential security threats, AI is only as smart as people teach it to be. So for trying to prevent novel sophisticated attacks, if the AI isn’t learning the right algorithms, it could end up making your defenses weaker. By and large, it still makes sense to adopt new security innovations like AI, but you also need to have the human touch from experienced professionals to ensure AI isn’t causing security problems instead of solving them.
In a typical Chuco engagement, we work with clients to understand their business risk profile and evaluate the alerts they are receiving in the test environment to sort the low priority or benign activity from the high priority and potentially malicious. As consultants, we familiarize ourselves with your unique security environment and ask questions so we understand what’s “normal” and what’s not. We get to know approved host names, approved software, and the typical schedule of machines in your system. We also get to know the approved users, and how User A in your network behaves versus User B.
Once an assessment has been made of each alert, we take one of several actions: set labels, suppress the alert, remove it entirely, modify and tune it, or promote the alert to the next phase of testing.
After that, it’s a case of rinsing and repeating through another phase. Once you’re confident that the alerts and events you’re receiving are identifying issues that require further investigation, you’re ready to push out the configurations system-wide in a production environment.
Of course, it’s helpful if your CISO and/or the security ops or threat response team is able to define up front what types of activities they want to receive alerts on, such as suspicious behaviors, specific campaigns of malware, or a specific compromise called to their attention by the FBI. Or, they may ask for general alerts on anything related to crypto mining or exfiltration of data.
In some cases, we also have had clients who are mainly looking for HIPAA or SOC2 compliance alerts, so that they can fulfill their compliance obligations.
At Chuco, we can work with you to create and update customized alerts based on new attacks being reported in the wild, or based on company policy and/or priorities, as well as import known indicators of compromise.
Regardless of your priorities, it’s essential to have processes in place to ensure that each type of alert is assigned to an analyst or other individual whose role it is to investigate and take mitigating steps as needed. We’ve supported smaller organizations where each team member is wearing multiple hats – as well as larger organizations with dedicated teams focusing on threat hunting, alerts and policy, plus engineering and devops teams who contribute to security operations. Chuco experts can work with you to define roles and establish processes, and offer additional support around Tanium if needed.
The advantage of getting your Tanium security alerts under control is that you can make the most of Tanium Threat Response and quickly identify potential attacks, vulnerabilities and malicious insider behavior. Furthermore, it makes your team more efficient – so that they’re not burdened with having to manually sort through an inbox full of false positives.
Configuring Tanium Threat Response and keeping on top of updates can require a significant investment of time and attention to detail. Contact Chuco if you need help with tuning and maintaining your security alerts – taking into account the people, process and technology considerations particular to your environment.
Introduction
This document describes a process by which you can compare a list of host names generated from one or more sources against a list of systems currently managed by Tanium. Instead of manually searching Tanium System Status for individual machine names, you can utilize Microsoft Excel to perform the analysis and quickly extract a list of unmanaged (or managed) endpoints.
For example, you could export a list of computers from an Windows Active Directory container and compare it against a list of Tanium managed endpoints. This solution supports lists containing up to 1,048,756 rows (current limit of Excel workbook rows). By using Excel, these comparisons can be completed quickly and efficiently.
This process leverages an export of the Tanium System Status content and supports comparisons against the following criteria: Fully Qualified Domain Names (FQDNs); short names; or IP addresses. The Excel workbook utilizes variable names for sections of the Excel workbook and the formula uses VLOOKUP calls to perform the analysis. Once created, this workbook can be reused with future client data sets. You will simply need to export a current data set from Tanium System Status, and compare with your new data set.
Exporting and Formatting System Status Data
In order to export data from Tanium, you will need sufficient privileges to access the System Status page. If you cannot access the Main Menu à Administration à System Status page in the Tanium console, you will need to request access from a Tanium administrator.
1. Before exporting the data, ensure your user preferences are configured to export headers. In the upper righthand corner of the console, click on your username and select Preferences from the menu:
2. Check the box for “Copy/Export with headers by default”
3. Once on the System Status page, modify the filter on the right side of the console. Change the filters to “30” and “days” instead of the default of “1” “Registration Intervals (4 minutes)”.
4. Export the file as a .CSV file.
5. The export function will automatically name the file based on the time the export function was run. You can save the file with a different name.
6. The file will be downloaded via your browser. The .CSV file should be visible in your Downloads folder. Double-clicking the file should open it in Excel assuming Excel is installed on your workstation.
Once opened, immediately save the file as an Excel workbook (.xlsx extension)
7. Delete all columns after column C, leaving the Host Name, Network Location (from client), and Network Location (from server) columns.
8. Move column A (Host Name) to column D.
9. Create a new header for column A called “Short Name”
10. We need a method to pull to the host “short name” from the list of fully qualified domain names in column D. This formula will calculate the short name for each “Host Name” found in column D.
Copy the following formula into cell A2:
=IF(ISNUMBER(FIND(“.”, D2)), LEFT(D2,FIND(“.”,D2) – 1), D2)
11. Copy the formula all the way down for all remaining rows in column A.
Once completed, your worksheet should look like this:
12. Next, we will assign Excel names to sections of the worksheet. Once these sections are assigned names, they can be referenced by formulas on different worksheets of the workbook.
Highlight the entire table but exclude the header rows. In our example, cells A2 through D24 are selected. Once selected name the region REG_SHORT and press Enter to save the name.
13. We need to perform the same steps for 3 more worksheet regions. REG_CLIENT_IP will reference the range of cells in columns B through D. REG_SERVER_IP will be assigned to the data in columns C and D. Finally, the last section of data in Column D will simply be titled REG.
14. Save the workbook.
IMPORTANT: It must be saved as an Excel workbook. A CSV file will not support the formulas and multi-worksheet solution described in this document.
ADDING A LIST AND CHECKING NAMES
The section describes how to crosscheck lists of IPs, hostnames, and short names against the Tanium data we imported into our workbook.
Note: The data you import here could be from any source including:
Regardless of the data source, the data must be formatted consistently with one entry per line. You may need to format it before copying into Excel, or you could try importing the data directly into a worksheet and let Excel format it depending on the file delimiters.
Note: Do not mix and match data with different delimiter types in the same file. You can only specify one type of delimiter when importing a file into Excel. Excel will not prevent you from importing a mash up of different data types, but the data will not format correctly in Excel.
In the first example below, we’ll be using a list of short names.
SHORT NAME LOOKUP
1. Copy the list of names that you want to crosscheck. In the example below, a list of server names was manually generated. Only some of the servers in the sample list have a client. Using the named Excel ranges we created previously, we’ll create a formula to perform lookups against the short names we generated in Step 11 of the previous section.
In the example below, a small data set of short names and IP addresses has been imported into a second worksheet called Azure (to simulate a list of Azure based systems).
2. In this first example, we’ll performing a lookup of short names against our existing Tanium data. Cut the IP Address column and paste into Column A of a third worksheet. Call this third worksheet IP Address. We’ll be using this list of IP’s in the second example.
3. To perform the lookup of our imported data against the Tanium data, we will need to use a formula. Since the ResourceName data looks for short names, we will be looking for Clients using our REG_SHORT data that we created in Section 1. If they were IP addresses, we could use REG_CLIENT_IP and/or REG_SERVER_IP.
In column B, we perform the VLOOKUP calls. In cell B2, add this formula:
=VLOOKUP(A2, REG_SHORT, 4, FALSE)
Rows returned with an “#N/A” means the short name lookup was unsuccessful for that host name. If the lookup is successful, it will output the 4th column (that’s what the “4” is in the formula) in the REG_SHORT name range, which is the FQDN that Tanium has recorded (i.e., what the Computer Name Sensor outputs).
*NOTE: If the data source contained fully qualified names and you just wanted to check against Computer Names, you would run the VLOOKUP against REG and not REG_SHORT. If you use REG, you have to use “1” instead of “4”. If you use REG_CLIENT_IP, you would use “3”
4. Copy the formula from cell B2 all the way to the bottom of your imported data set.
5. To quickly identify all systems that have a Tanium client, you can use the Excel data filter function.
A. Select the Data tab of the worksheet
B. Select column B so that it is highlighted
C. Select the Filter button.
6. Select the filter button at the top of Column B. Clear the checkbox for #NA. Click OK. This will leave you with just the systems that have had active Tanium registrations in the last 30 days, in comparison with the list of systems you provided.
In this case, we’ve found 6 Tanium Clients out of 19 Azure VMs.
If you need to send this end result to someone, the best way is to copy that list of output (with or without the #N/A) and paste just values into a new Excel document and send that, so none of the System Status or formulas get sent too.
IP ADDRESS/NAME LOOKUP
In the previous section, we saved the IP addresses from our original list to new worksheet in our workbook. We’ll be using the IP Address worksheet for this example. If you are performing this step from scratch with just a list of IP addresses, copy the list of IPs that you want to crosscheck. In the example below, a list of server names was manually generated. Only some of the servers in the sample list have a client. Using the named Excel ranges we created previously, we’ll create a formula to perform lookups against the IP addresses we defined as the REG_CLIENT_IP in step 14 of the previous section.
1. To perform the lookup of our imported data against the Tanium data, we will need to use a formula. Since the ResourceName data looks like short names, we’ll be looking for Clients using our REG_SHORT data that we created in Section 1. If they were IP addresses, we could use REG_CLIENT_IP and/or REG_SERVER_IP.
In column B, we’ll do the VLOOKUP calls. In cell B2, add this formula:
=VLOOKUP(A2, REG_CLIENT_IP, 3, FALSE)
If you see an “#N/A”, it means it wasn’t successful in finding the short name. If it finds a Client, it will output the 4th column (that’s what the “3” is in the formula) in the REG_SHORT name range, which is the FQDN that Tanium knows about (i.e., what the Computer Name Sensor outputs).
Introduction
If you have not had the chance to use or see one of the Tanium appliances in action, you are missing out and I suggest you reach out to your TAM as soon as possible and inquire about them. Here at Chuco we are loving what Tanium is doing with this platform and how it benefits you as a customer. An appliance allows you to get rid of licensing costs for Windows and SQL (sorry Microsoft) as well as the overhead of managing yet another multi-system environment’s needs. Along with that, in our experience and testing, Tanium running on an appliance outperforms a standard Windows-based installation in many ways. TanOS 1.3.0 was released May 24, 2018, and 1.3.1 followed shortly after on July 3, 2018. These releases bring with them some major feature updates and improvements over what was available in the previous 1.2.x releases. In this article, I will address some of the features we are most excited about.
Appliance Roles
TanOS 1.3.x introduces role-based access management (RBAC) to the appliance. You can now create user accounts for appliance management and assign 1 of 2 roles to this account, tanadmin (root level access) or tanuser (view level access).
Appliance Logon Visibility
Along with the ability to create accounts to manage the appliance, you can also view the last 20 successful or failed logins and login statistics for those accounts. Rather than sharing a single account like in 1.2.x you can now set your administrators up and see who logged in, when and from where.
TanOS Virtual Appliance General Availability
This virtual appliance is something Chuco has been using in our lab since the release of 1.2.1 and it is an amazing step forward for Tanium. While only approved for pre-production labs, the GA release of 1.3.1 is a great compliment to the hardware appliance in that allows you to host a dev/test version to better manage a like for like promote to production and testing model.
SYSLOG and Email Alerting
TanOS 1.3.x introduces the ability to send appliance alerts using SYSLOG or Email as the means of delivery. This function has been added to the appliance maintenance screen. Since the appliance can not be managed or monitored from an OS perspective due to the lack of access to the system shell, this is a fantastic feature for enterprises where availability or issue resolution timeliness is key.
Database Operations Additions and Menu Consolidation
In TanOS 1.2.x you could do database monitoring (found in the Tanium Support Menu), backup the Tanium database (found in the Appliance Maintenance– > Backup/Restore Menu), and restore the Tanium database (also found in the Appliance Maintenance– > Backup/Restore Menu).
In TanOS 1.3.x you now have the ability to manage all Tanium database functions in the Tanium Support menu under Database Operations, including some new options like Monitor Database, Database replication and failover options.
If you are interested in seeing the full list of feature changes and updates you can find it here:
https://kb.tanium.com/Category:TanOS
Deploying applications and module content can be challenging, especially when you need to work around 20 different change windows that depend on location, application, OS, system or server type (the list goes on). Here is an example of how you can use the Client Maintenance content in Tanium to help sift through all that without needing to issue an Action per maintenance window.
Maintenance window content is currently only available for Windows operating systems and can be a powerful means of simplifying how you target a wide range of servers with different change windows – with just a little upfront time spent on setup.
Note that this is different from maintenance schedules you may have set up in the Patch module for example, to deploy your Windows updates.
In the example below, I am going to leverage my “Windows Workstations” Action Group to set a basic, scheduled deployment of my desired maintenance window settings. As I am sure you are already aware, carefully crafted Action Groups are essential when using Tanium. If you haven’t done so already, now may be a good time to examine your current Action Groups as well as the Computer Groups that populate those Action Groups. You will also want to have an outlined maintenance window policy to work with. While this process can be used in an ad-hoc manner, it is neither recommended or suggested.
HOW TO SET UP MAINTENANCE AND REBOOT
Option 1 – Ask your Technical Account Manager (TAM) for the latest version of the “Maintenance and Reboot” content. Then import it into the Tanium Console by going to Authoring à Sensors or Packages à Import from XML
Option 2 – Import the content using Tanium Solutions Labs Content Import. Note that this option is not available on your production Tanium Server.
HOW TO DEPLOY A MAINTENANCE WINDOW
1. Start with a basic question to find our Windows Workstations without a configured or enabled maintenance window:
” Get Maintenance Window Enabled not contains yes from all machines with ( Is Windows contains true and Windows OS Type contains workstation and Maintenance Window Enabled not contains yes ) “
NOTE: Negative filtering is by and large not preferred, however, in this instance because Maintenance Window Enabled contains 3 states (yes, no, <not defined>) we want to capture all systems without an enabled Maintenance Window in as simple a question as possible.
With results returned containing what we want, we will now save this question to use as a means of quickly filtering endpoints for future deployments.
2. You can now ask your newly Saved Question and when you get your values returned, check “<Not Defined>” and/or “No” and – click “Deploy Action”
The Action we are going to use to set the window is “Maintenance – Set Maintenance Window Parameters”
For this example I used Monday – Wednesday since I am working with client systems. Most enterprises generally consist of laptops these days or have policies in place to shut down workstations over the weekend, so setting a weekend schedule doesn’t quite guarantee I will hit my intended audience. For your implementation just keep in mind “knowing your audience” is the key to this. Because this is completely customizable, you can set your servers to run Fri – Sun but only on even days, or the third week of every month and on and on.
Note that one limitation is you can’t schedule a maintenance window for more than a 3-day period. So, no M-F 8A-5P schedules for your users or servers. Beyond that, you are free to move about the cabin.
3. Now we can do 1 of 2 things. A single Package deployment to assign the window settings in a “one and done” type fashion, or like in the screenshot above, you can set it to reissue on an interval using the “Reissue Every” option. In my example, the Action of applying my maintenance window policy will check every 4 hours if there are more machines that matched the criteria we selected in the Saved Question. If it finds any new endpoints that meet the criteria, the Action will run on those endpoints. This prevents the need to continually check for machines with no maintenance configurations if no machines are found that fit the Action’s target criteria, no Action, is issued.
Click “Show preview to continue” and “Deploy Action” to complete the Action. If you created a recurring Action or set the start time in the future, you can review the Action by going to Scheduled Actions under Actions in the Tanium Console. If you set the Action to reissue, you’ll see a “Yes” under the Policy column.
LEVERAGE YOUR NEWLY ASSIGNED MAINTENANCE WINDOW FOR CONTENT DEPLOYMENT
Once you have configured some endpoints for maintenance windows, you can leverage – the “In Maintenance Window” sensor whenever you want to account for maintenance windows. The example below is deploying Tanium Trace.
First, ask a Question that outputs Trace Status and use the “In Maintenance Window” Sensor:
Second, save the Question in case you’d like to revisit:
Then, select the output from “Tanium Trace Status” that you want to deploy to and click on the “Deploy Action” button.
CONCLUSION
For maintenance windowing to work in this workflow, you must reissue the Action at an interval that is smaller than your smallest maintenance window. In the example case where you have critical servers that have a maintenance window of 2 hours, we need this Trace Action to fire off frequently enough to catch our critical severs in their 2-hour window.
The above policy Action with 1-hour interval will look for systems needing the Trace Tools installed that are in their maintenance window. If the Action finds endpoints that meet the target criteria, the content will be distributed automatically to the systems. If there are no machines that meet the criteria (maybe there are no active maintenance windows, or Trace is fully deployed), then no Action is issued. Once this workflow has completed for our Trace deployment example, you can manage your complex maintenance windows moving forward, without having to alter any Scheduled Actions in Tanium.
Normally this kind of configuration for a Tanium product module should be fairly straightforward, but I ran into a bug I hadn’t seen before, and spun my wheels for awhile. So — I figured I’d document this in case anyone else needed it.
OS fingerprinting is one of the more interesting use cases for unmanaged assets (now known as Tanium Discover). But, the functionality is disabled by default because Discover’s OS fingerprinting relies on Nmap (this is common for other fingerprinting products as well).
HOW TO SET UP DISCOVER
When you import Tanium Discover and go to the workbench in the Tanium Console for the first time, you will need to do a couple of things prior to seeing unmanaged assets (btw – Tanium defines an unmanaged asset as something that doesn’t have the Tanium Client running on it).
1. First, you need to configure the background service account. This is insanely easy and almost not even worth mentioning. Just click on the gear icon in the upper right and supply a Tanium userid and password. The only thing you need to remember is this must be an Administrator-level Tanium account.
2. Second, you need to set up a discovery method. There are a few options that you can read more about in the Discover User Guide, but what we’ll look at now is the Nmap Scan Discovery option.
Be sure to think about which Computer Group you want to target. In production, you’ll want to be very careful which network segments you choose to initially test OS fingerprinting on. Nmap’s fingerprinting has unfortunately been known to take down fragile computer systems. For my own home lab, I am simply going with All Computers.
Go ahead and click Save. If you took at a look at the Configuration dropdown, you will notice that there is “Host Discovery” and “Host Discovery + OS Fingerprinting”. Clearly we will want the latter, but for testing purposes, lets leave out fingerprinting and make sure that the basic functionality is there.
Once saved, Tanium Discover should be in a functional state. However, you will need to wait for a few Scheduled Actions to fire off before you start seeing results.
3 (optional). If you are impatient like me, you can simply re-issue the Actions needed to get everything set up. In the Tanium Console, go to Menu -> Actions -> Scheduled Actions and filter all of the Scheduled Actions by the word “discover”
You will notice that there are 3 steps involved to priming the system. You’ll see 6 because Tanium doesn’t support multi-OS commands in a single Action yet, so there are 3 for Windows and 3 for Linux distributions.
To avoid waiting an hour or two for the default Actions to kick in, you will need to re-issue the “Distribute Scanner Tool” Action, then the “Distribute Configuration” Action, and finally the “Execute Scan” Action. To be conservative, wait for each re-issued Action to complete to at least the majority of your environment before moving on to the next Action.
VERIFYING THAT DISCOVER IS WORKING
There are a couple of ways to see if Discover is working, but the simplest way is to just ask for Unmanaged Assets via Interact.
The Unmanaged Assets Sensor is what drives the data collection for Discover. You should also check out the various columns you can unhide too. The second method to check is to use Discover :). But — if you’re just setting it up, you may need to click on the “Discover Unmanaged Assets” in the upper right hand corner of the Discover Home tab.
ADDING OS FINGERPRINTING
After verifying that the basic Discover functionality was working, what I did was go back to the Discover configuration page, and simply changed the Nmap Scan Discovery Method from “Host Discovery” to “Host Discovery + OS Fingerprinting” (I mentioned this above).
You would expect that the configuration would then sync down to the endpoints within at least 45 minutes (what the default interval is for the Distribute Discover Configuration Scheduled Action). BUT — after nonchalantly waiting for an hour, nothing changed. I was still seeing “unknown” for OS Platform.
After a bit of digging, I noticed that the configuration file on the endpoint still had the fingerprinting capability disabled, so I re-issued the config distribution Action. I then noticed that the targeting of the Action only points at machines that don’t have a configuration file. What this means is, edits to configuration in Discover will simply not work. In my lab, I was able to go to my endpoints and manually delete the configuration file (a more patient Tanium purist would have used an Action) and get the configuration updated. After this, I finally got some OS fingerprinting!
But if you’re in production with a lot of endpoints, removing the configuration file isn’t practical since you’re not able to easily ensure that all of your machines get the Action, nor would you want to do this anyways for each time you want to change the configuration. So that leaves you with having to recreate your Discovery Method every time you want to make a change, until the engineering team fixes this issue.
Here’s a short guide on how to get started with the Tanium Server SOAP API. This continues some of the discussion from the Integrations Through the Tanium Server API article and walks you through a quick way to immediately start playing with the Tanium Server API. Keep in mind that this doesn’t use the Pytan Python Wrapper project and instead (for better or most likely worse) focuses on the raw SOAP API.
To follow along, you will need:
A functional Tanium Server and user login.
The console.wsdl file out of the Tanium Server’s installation directory.
the Chrome browser on a Mac or Windows machine – when I’ve documented how to get started with the SOAP API in the past, I’ve always relied on a product called SOAP UI. But, I’ve got a Mac and the performance is terrible, so I decided to look for a new tool. And really, we don’t need much… just something that can send SOAP requests easily and see the response.
Another thing to keep in mind is, this quickstart should be used prior to any sort of actual API integration work. If you don’t understand what is happening at a basic level here, then you’re setting yourself up for failure when you move on to actual integration programming/scripting.
SETUP
First, open up Chrome and Google for “boomerang soap”. Boomerang is a fairly simple and straightforward Chrome extension/app that does exactly what we need: send and receive SOAP requests (and REST, which will come in handy for future quickstart articles). Best of all, it doesn’t hang my CPU.
After setting up, your Boomerang setup process should look like this:
Step 1: Create a new project
Step 2: Add the local location of the console.wsdl file and give the service a name
CREATING YOUR FIRST REQUEST
Once you’ve got your SOAP service set up, the next step is to create a new request.
Boomerang (and most other tools like this) creates a request with a skeleton created from the WSDL file and actually gives a pretty extensive template for what the request can look like.
Unfortunately, the Tanium Server’s API WSDL is fairly broad and is a bit too much (at least for me). A few years back when I was learning the API, I would keep the console.wsdl open in a text file (or XML-friendly viewer) so that I could review what each of the elements in question were. In most of the API calls you will make, there are three primary elements that you need: “auth”, “command”, and “object_list”. And since the rest is usually unnecessary, just delete it all so that it looks like below. You’ll notice I’ve added “system_status” to the “object_list” — more on that below.
HOW TO AUTHENTICATE
Back in the day, you had to actually pull a session ID out of the “tanium” database and use that in a <session> element. But since that was tremendously unsafe, Tanium moved to an auth model where you actually needed to provide a userid and password. Initially, this sounds just as unsafe as a session ID, but its almost like a necessary evil. Once you authenticate and continue using the API at a good frequency, you can move to utilizing the session ID that is put in the response back to your first API call. In other words, you can stop using your userid and password and just use this temporal session ID.
In order to authenticate, all you need to do is fill out the “auth” element. The easiest thing to do at this point is to delete “domain” and “secondary” and fill out “username” and “password” just as you would the Tanium Console). Once you’ve successfully made a request to the Tanium Server API, it will actually pass back a session ID. Once you’ve got this, you can just use the “session_id” element instead of the “userid” and “password” elements.
Unfortunately, you need to specify a “command”, so what I typically do is specify “GetObject” as the command and add something like “system_status” to the “object_list” — more on this in a few paragraphs, just bare with me here.
At this point, you’ve executed a basic SOAP request, and have successfully used the Tanium Server SOAP API! But, since you probably have no idea what system statuses are (or maybe you do, and you can stop here), lets do one more example that you will probably understand easier.
HOW TO READ A SENSOR
Once you have the session ID, use that to create the next request. Keep in mind that if you don’t use the session ID quickly enough, it will expire. Also keep in mind that you may get back a new session ID in a future response that you should use instead to keep the session going.
Lets try to get the definition of a Tanium Sensor. And, lets also avoid using the previous username/password method we did above. First, lets use the new session ID by adding the “session” element directly under “tanium_soap_request” (you might think it should go under the previous “auth” element, but it doesn’t). Second, under “object_list”, lets change “system_status” to “sensor”, and look for the Sensor by name (you can also look by ID or hash, but name is easiest at this point).
What you’ll see in the response is the full definition of the Sensor named IP Address (an obvious fan favorite of Tanium operators everywhere). You get the full slew of data including ID, hash, category, and more.
ADDITIONAL CAPABILITIES
There’s obviously a lot more you can do with the SOAP API. For now, take a look at the WSDL definition if you want to play around with more commands and objects. Keep in mind to use a development environment! I can’t tell you how many times experienced operators have accidentally done something stupid to a production environment because they thought they really knew what they were doing.
Really useful API calls include creating questions and getting responses, executing actions, and getting information about the Tanium Server itself. If you wait a week or two, I’ll have more posts that describe these, as well as parallel posts that include how to accomplish these tasks with the Pytan Python wrapper.
During a recent training, someone in the room was going through some hands-on training activities on how to ask Tanium Questions. As he was working through some Questions using some filters, he asked what a lot of others ask about: Can you use regular expressions in Questions?
The answer to this insanely common question is yes (if you’ve upgraded to Tanium v7.0).
USE THE “MATCHES” FILTER FOR REGULAR EXPRESSIONS
When you want to use regular expressions to narrow down the results from a Question, you need to use the “matches” keyword. Keep in mind that your regular expression needs to match the entire Sensor result. For instance, if you wanted to find all the machines that have an IP address ending in 3 numbers, you can’t just use “\d{3}^”. Instead, you need to account for the beginning of the IP address with “.*” (or something fancier, if you really want to show off).
LAZY EXAMPLE FOR FINDING IP ADDRESSES ENDING WITH 3 NUMBERS
If you want to do a really quick and basic test for a regex match, you can do something like this. In the “Ask a Question” field, simply ask for “IP Address matching “.*\d{3}”:
Once parsed, you’ll be able to quickly find the correct structured Question you want. In this case, you can click on “Get IP Address matching “.*\d{3}” from all machines” and see:
BETTER WAY TO SEE FILTERED RESULTS WITH PLURAL SENSORS
You’ll notice that there are “[no results]”, which is why I called this basic Question lazy.
To do this properly, you actually have to use both sides of the Question like:
Did you notice that there are two matching filters? For a more detailed explanation on why you might need to have that filter in two places, check out yesterday’s post on what they are and how to avoid them.
Additionally, if you didn’t care about the IP address data itself and wanted the computer names too, you could simply add Computer Name to the Question:
TIDBIT
As a small tidbit, I think its interesting (hopefully I’m not the only one) that the Tanium Server uses regex under the covers to implement many of the other filter keywords. As an example, The Tanium Server translates “starts with abc” and converts that to a regex match of “abc.*”.
![What is [no results] and How to Avoid It](https://chuco.com/wp-content/uploads/2020/12/article_basictipsaskingq_fig3.png)
Here’s a related follow up from Friday’s Basic Tips on Asking Questions article. In some cases you may run into “[no results]” when you’re first ramping up on how to use Tanium. In most cases, asking a Question with “[no results]” is perfectly harmless, but a lot of seasoned Tanium users will proclaim that its less elegant. Regardless, here’s why it happens and how to avoid it (if you want to).
WHAT IS [NO RESULTS]?
“[no results]” occurs when a Tanium Client evaluates a Question, decides it needs to produce a result, but has no result to send back.
There are a couple of common ways that the Tanium Client can get into this situation.
1. YOUR SENSOR SCRIPTS NEED WORK
This one is fairly straightforward — your scripting needs to be more complete. If a Tanium Client is executing your script and it gets into a path where there is no actual stdout output, then you’re going to hit “[no results]”. Or, if you create a Sensor and assume it will only be run on Windows, but it gets run on Linux, then you’re going to hit “[no results]”.
HOW TO AVOID
First, make sure that you’ve got OS coverage — make sure you’ve got a Sensor script for each operating system in your Tanium environment. Second, make sure each script is assured to have at least some stdout output. Even if you have to put something like “N/A on Solaris”, thats still better than having to see “[no results]”.
2. YOUR QUESTION AUTHORING NEEDS ATTENTION
If you’ve learned to tackle the first source of “[no results]”, then you’ll likely be able to avoid a lot of the problem. But if you’re still seeing it, its likely due to how you are asking Questions. To explain how this happens, first remember that the second half of the Question instructs a Tanium Client to answer or not answer a Question (see the Tips article from Friday to understand). And, remember that if you add a filter to a Sensor in the first half of the Question, you are potentially eliminating results. If you have a filter that eliminates them all for a computer, then you will hit “[no results]”.
Take this example where I want to find all machines that have an IP address ending with .1:
In this case, I incorrectly used “from all machines”. Not only did I get the values I wanted (10.8.103.1 and 10.8.108.1), but I also got “[no results]” back from the other 1140 machines that have no IPs that match that. There’s a hidden inefficiency since those 1140 machines had to evaluate the IP Address Sensor. In this case, the Sensor used is pretty cheap, but if you were using an expensive Sensor, look out!
The more appropriate way to do it isn’t obvious, but you get used to it.
HOW TO AVOID
In order to avoid these kinds of “[no results]”, you have to ask a slightly more complicated Question. If you remember, I failed when I specified “from all machines”. Instead of doing that, what I should have done was:
As you can see above, by using the added Question filter at the end to ensure that the two machines I’m looking for are the only two to answer. Also, you might be wondering why I left the first filter in the first half of the Question. In some cases, you don’t need it. But since the IP Address Sensor is plural (i.e., it tends to produce multiple results). If you took it out, you would be getting back ALL IP addresses (which we don’t want) from machines that have the IPs that we are looking for.