This post was co-written by Charlie Klein
First things first, why would you want to collect logs from Palo Alto and send them to a Cloud SIEM? There are many reasons. At its core, having a centralized location with a consistent user experience for managing alerts, notifications, and information coming from the technologies securing your environment can provide value in a lot of ways. In this blog, we’ll discuss how to collect, parse, and analyze Palo Alto logs in Logz.io Cloud SIEM, and how it can help secure your cloud workloads.
Shipping Palo Alto Logs to Logz.io
So, where do we begin? Before beginning you should understand what the flow of data looks like. What we’re trying to accomplish is taking data produced by Palo Alto and forwarding it to Logz.io to be ingested. This should go some a little like this:
Palo Alto –> Filebeat –> Logz.io Listener –> Logz.io
The first step to setting up the above is to create or repurpose an instance of Filebeat. This way, we can have the instance listening for events before we start sending them. At a high-level, we’re going to configure Filebeat to listen for the events that we will export from Palo Alto, capture them, append some fields, and then send the events to a Logz.io listener. Once we have that setup, we can move on to making changes in Palo Alto.
In the Filebeat configuration file (/etc/filebeat/filebeat.yml), add TCP to the filebeat.inputs section.
Replace <SHIPPING-TOKEN> with the token of the account you want to ship to.
# ... filebeat.inputs: - type: udp max_message_size: 10MiB host: "0.0.0.0:514" fields: logzio_codec: plain # Your Logz.io account token. You can find your token at # https://app.logz.io/#/dashboard/settings/manage-accounts token: <SHIPPING-TOKEN> type: paloalto fields_under_root: true encoding: utf-8 ignore_older: 3h
If you’re running Filebeat 7, paste this code block. Otherwise, you can leave it out.
# ... For Filebeat 7 only ... filebeat.registry.path: /var/lib/filebeat processors: - rename: fields: - from: "agent" to: "filebeat_agent" ignore_missing: true - rename: fields: - from: "log.file.path" to: "source" ignore_missing: true
Then set Logz.io as the output:
# ... output.logstash: hosts: ["<>:5015"] ssl: certificate_authorities: ['/etc/pki/tls/certs/COMODORSADomainValidationSecureServerCA.crt']
In Palo Alto, we will need to modify some settings so we can send the logs to the instance of Filebeat. This entails knowing the IP address, port, and transfer protocol to use–essentially what machine Filebeat is on and where it’s configured to listen for events from.
Once you’ve added this information to Palo Alto, you can commit the changes and expect to see the logs start flowing to the server.
Start or restart Filebeat. At this point, Palo Alto logs will start streaming into Logzio. If you run into any snags, checking Filebeat’s own logs can be a helpful strategy for catching mistakes.
If everything has gone smoothly and you’re seeing your Palo Alto logs in Kibana, you’re ready to move on to the next step—parsing, which enables you to query for specific data.
Parsing the Logs
Logz.io offers parsing-as-a-service to anyone who has a Logz.io account (including free-tier and trials!). To place a parsing request to the support team, open the Intercom chat located in the application. Once you’ve done this, just say “Hey! I need to parse some logs.” They’ll ask you for some additional data and insight, and then proceed to parse everything for you, which should take no longer than 20 minutes.
Analyze in Logz.io Cloud SIEM
Palo Alto’s broad portfolio can monitor security threats in many different ways. One thing they all have in common is that they produce logs, which can be analyzed in Logz.io. By collecting logs from multiple offerings in a single place, Logz.io makes it easy to use one interface for alerting, visualization, and investigation.
Logz.io uses a rich set of rules to create events and alert users when certain threats or activity are detected by various Palo Alto offerings. As shown in the screenshot below, there are rules that will trigger alerts on connections to malicious IP addresses to a vulnerability exploit.
The top rule above, for example, will create an event indicating spyware detection if Palo Alto’s logs record spyware. You can set the rule to trigger a slack notification (or many other endpoints) if this happens a certain amount of times in a specified timeframe, as shown below.
These rules are essential from separating critical security insights from the rest of the noise. Modern SOCs are collecting millions of logs a day, and need a way to filter out information that could distract from attacks.
In addition to premade rules, you can leverage out-of-the-box Kibana dashboards purpose-built to provide a bird’s eye view of security events related to Palo Alto.
One of these dashboards is based on the traffic Palo Alto monitors that crosses a given organization’s firewall;, another is based on specific threats frombased on malicious IP addresses identified by our threat intelligence feeds. Palo Alto’s solutions generate logs with helpful information on the volume and type of traffic, which can be consolidated and analyzed all in one place so Palo Alto customers can visualize information such as:
- The amount of traffic sent or received from specific IP addresses.
- Random spikes in data sent across the firewall.
- Port activity across time.
- Different categories of urls users are accessing.
- Connections to malicious IP addresses.
These data points can all be viewed on dashboards designed to monitor this kind data, like the one below:
But don’t be limited by the dashboards already built for Palo Alto logs. Palo Alto logs are rich with information, and can be queried and analyzed for all kinds of insights in Kibana – which allows you to slice and dice your data however you want. Open up the log data, familiarize yourself with it, and create your own visualizations to draw additional information from the logs.
Beyond Palo Alto
Once you’ve acclimated yourself to this content, it’s time to start thinking about the bigger picture. SIEM’s can go further than just collecting Palo Alto logs. In fact, one of the core values of using a SIEM is that you have a single interface for alerts, visualization, and investigation.
If you are using other technologies to secure your environment you can collect alerts, notifications, and logs from them as well.
Learn more about Logz.io Cloud SIEM as a centralized place for collecting security related events!
Hopefully at this point you have a good understanding of how to collect, parse, and use Palo Alto logs in Logz.io’s Cloud SIEM. If anything is unclear, you can always contact Logz.io’s 24/7 chat support or reach out to the sales team for more information by requesting a demo.