Episode Transcript:
John:
Hello PANCasters, welcome back. Today we have a special guest, Olivier Zheng, one of our senior TAC engineers. He is gonna talk to you about Panorama and Logging.
Olivier:
Hello PANCasters.
Welcome back to this new episode of PANCast.
In a previous episode, we discussed about logging and why it is your best friend.
In case you did not listen to previous episodes, I invite you to check the previous episodes, it won't take too much of your time and you may find some interesting takeaways to improve your security posture.
Setting up Panorama as a logging solution looks simple but there are few points to check and consider before going into implementation.
If you are already using Panorama as a central management console, where you can manage the configuration of all your devices and cloud services, you can immediately see the advantage of using it as a part of your logging solution.
To do so, there are few questions to answer.
Olivier Zheng, PCNSE, is a Staff Support Engineer at Palo Alto Networks. As SME Management/Logging Reporting in Technical Assistance Centre Singapore, he is supporting customers and participating in multiple knowledge sharing initiatives by writing content in the Knowledge Base, by delivering training to internal engineers. He is responsible for 1 issued patent. Olivier holds a Master of Science Mobile and High Speed telecom networks from Oxford Brookes University, UK and a Master of Science in Computer Science and Information Technology from ESI SUPINFO Paris, France.
By that question I mean that you need to identify the required logs to keep.
It may sound obvious, but a log may stay for a limited period of time on the system due to log rotation. That is one of the reasons that if you need to keep specific logs, you would have to store them on a device other than the firewall. The main function of the firewall is to inspect and control the network traffic, not to store logs.
Also you will need to define what to keep, you can log everything as you can log nothing, that will depend on the local regulations, and your organization policies.
You may already have a solution to keep the logs, and as I say "never put all the eggs in the same basket", you can easily integrate Panorama in your current logging solution.
The logging profile allows you to configure with a fine granularity thanks to the query builder different rules so specific logs can be forwarded to different systems: you can choose to forward all the logs to a simple syslog server and choose to forward system logs containing a specific keyword in its description to Panorama for instance.
Also a practice which is seen in some deployments for traffic logs is to log the "session start". So just to bring back some context : the firewall offers the possibility to log at the start of a session when the first packet is received and at the end of the session when the session is blocked, or at the end of the session.
The question you need to ask yourself: is the information in the session start required and worth the resource cost or not? If you compare the information in the session start log and the session end log, the main value of the session start is to see the traffic information at the session opening.
This practice should only be used for troubleshooting purposes, so disable the "session start" to reduce the impact on the firewall and on the Panorama resources, we will discuss later that point.
To avoid any surprise, it is better to identify what to keep. So the day you need a specific log, you know where to look.
Now that we know which logs need to be kept, we can start to think about sizing the Panorama deployment. There is not a "fit all" design, it will depend on your organization constraints and requirements.
A standalone Panorama can store logs for 1 branch firewall for instance but it will not be able to store logs for all your organization's data center firewalls.
For redundancy, you can consider to get copy of logs directly on the Panorama thanks to the RAID disks or you can directly opt for log redundancy by setting up a collector group. Panorama hardware appliances set a RAID mirroring for each logging disk, so if a disk gets faulty, the data is still present on the mirrored disk. The log redundancy on the collector group will create replicas in the cluster, this has a cost on the Panorama: due to the constant synchronization of the data, the effective logging rate a log collector can process is divided by 2 compared to a log collector in a collector group without the log redundancy enabled.
Please note that you can also have both : RAID disk for disk failure prevention and Collector Group redundancy to mitigate a node failure.
In case there is a geographical requirement, keep in mind that the communication between Log Collectors requires the latency to be below 10ms.
Finally like I said earlier, integrating Panorama to an existing logging solution is easy, Panorama can act as another log receiver or it can centralize all the logs then forward it to other servers.
What is the expected logging rate sent by the managed devices to Panorama? That will depend on the number of devices configured to forward their logs to Panorama: with an equal logging rate per firewall, the more firewalls sending logs, the higher the logging rate will be. Then, you need to evaluate the logging rate by evaluating the overall number of sessions on each firewall. Why the number of sessions? The logs related to the traffic are all session based: a high traffic session can generate the same amount of logs as a denied traffic session.
The overall logging rate will allow you to size the overall Panorama deployment, and the number of sessions per firewall will help you to make sure that the Panorama model is correctly sized to your needs. You can find at the end of the transcript our calculation guide to help you to size correctly your deployment.
Although the software running on the Panorama appliance is the same, the difference between each model explains the capacity to handle a certain amount of incoming logs. It is good to know that a Panorama running in “log collector” mode will be able to ingest more logs per second than a Panorama in "mixed mode": in the first case, the whole resources of the Panorama are used for log ingestion but in the mixed-mode, the resources are shared by more processes.
Finally, as network usage evolves over time, it is safe to set a "blanket" on the estimated logging rate from the firewalls.
Once you have the answer for the 3 questions, with knowing the retention period of your logs, you will have an idea on the total disk space you will need, the type and how many Panorama appliances will be needed.
That's all for today, the takeaways for today:
Finally, this episode's transcript and the relevant knowledge base links can be found at live.paloaltonetworks.com under the PANCast section.
Check out the full PANCast YouTube playlist: PANCast: Insights for Your Cybersecurity Journey.
Related Content:
