This solution is very important for our network. We use it for the data on our servers and for our internet connections. We also use it for all of our user devices to connect to outside corporations. The IPS on our devices prevents any issues from occurring. We use the on-prem version of this solution.
We currently upgraded our devices to a new version. We have noticed a performance increase. We tested filtering features and it's an interesting feature that helps us with our tasks. We don't need very complex features.
It's a high-performance device. The network performance is also really good. We check how much time it takes for the servers. Our network performance has increased since using this solution.
We have a local consultant for this solution. They can handle most of the operations with my team. We work together with the consultant sometimes for complicated scenarios like migration.
The initial setup is difficult. It took me three tries to get it right. The setup took two or three hours. We migrated from an old to a new one. It's not so complex but Check Point is complex in comparison to other firewalls. For example, Palo Alto is easier to install than Check Point.
We negotiate every deal to get a discount for a higher number of devices.
I would rate it a nine out of ten and I would recommend this solution. Their support team should be faster because sometimes when we need support their responses are late.
Auto-Scale Palo Alto Networks VM-Series Firewalls in a Public Cloud Environment
For environments that require an automatic deployment as scale out of the security services is required, you can
combine bootstrapping with additional automation that monitors the security services and, when performance limits
are reached, triggers (CloudWatch) the automatic deployment and bootstrap of a new firewall to the security layer.
Auto-scaling works differently in every environment because tools that are specific to each public cloud environment
monitor and trigger the firewall deployment. Auto-scaling in AWS uses AWS services such as Lambda, Amazon Cloud-
Watch, S3, and SNS, in addition to the APIs and bootstrapping on the firewalls. In Azure, you use AppInsights and
Virtual Machine Scale Sets to monitor the environment and trigger the automatic deployment of a new firewall. You
can use a number of metrics in order to trigger the auto-scale event. Examples include:
• Data Plane CPU Utilization %
• GP Gateway Utilization %
• Active Sessions
• Data Plane Packet Buffer Utilization %
• SSL Proxy Session Utilization %
• Session Utilization %
Just like in the previous example, you must create the bootstrap container before automatic scale-out. The automation
monitors the appropriate metric on the existing firewalls, and after the value is higher than allowed for the right amount
of time, the scale-out event triggers the same firewall deployment as in the previous example. After the firewall is deployed and has a configuration provided by Panorama, the auto-scale automation adds the new firewall to the backend pool of the load balancer, ensuring that traffic load is appropriately distributed to the new firewall.
Operational Response to a Changing Environment
In virtual private data center and public cloud environments where new compute instances are created as needed for
scale, the administrative overhead in managing security policy can be cumbersome. Using dynamic address groups in
security policy allows for agility and prevents disruption in services or gaps in protection.
The VM-Monitoring Agent on the firewall can pull IP address and tag information from the cloud environment. Predefined dynamic address groups use the tag information to automatically associate IP addresses to pre-defined rules in the security policy. When there are multiple firewalls in the environment, they all can monitor the same source for IP and tag information. This provides the firewalls a dynamic but consistent view of the resources within the environment.
Dynamic address groups allow the firewall security policy to respond to a changing environment, but the applications
running in the environment must be well known for the appropriate dynamic address groups and security policy rules
to be created. Configuration automation can be used to provide a security policy that automatically is configured when
new applications are deployed to the environment.
Security Response Based on Log Information
Although log information alone can be extremely valuable to a security administrator, manually sifting through the logs
and responding to security events takes too long and requires too many administrative resources. Automated security
actions in the firewall can respond when a previously identified scenario presents itself in the logs. For example, when
Panorama sees a correlation event, it can use the source IP address from the log and use auto-tagging to attach a predefined tag, such as “Compromised.”
You can configure a dynamic address group on the firewall that is associated to the IP addresses with the “Compromised” tag. You can then create a security policy that blocks the traffic or enforces multi-factor authentication (MFA) for these endpoints that uses the dynamic address group as the source. If the user on the endpoint is malicious, MFA blocks their attempt to move laterally within the network, protecting sensitive data.
If the user continues to attempt to move laterally, Panorama can automatically use additional tags to block the IP and
HTTP log forwarding to log an incident. Panorama can use the ServiceNow ticketing system HTTP API to create a ticket so that the operations team is aware of this action on the endpoint. They can then investigate the incident, remediate the endpoint if needed, and remove the associated tags the apply the enhanced security policy.
Security Response to Improper Cloud Environment Configuration
RedLock cloud security provides organizations configuration security alerting for AWS, Azure, and GCP environments
and provides integrations that allow remediation to be automated. Using auto-remediation, organizations can make
sure alerts are automatically remediated before they, or malicious actors, even know there’s an issue. For example,
reconfiguring a security group rule that allows ingress traffic from the public Internet and opening a ticket with Service-
Now for tracking minutes after it’s been created.
RedLock uses the following automation process to remediate issues:
1. Using the cloud environment’s API, continuously perform checks against the configured signatures and policies.
2. If the resulting analysis determines a signature did not pass, send the failed alert to an integration such as
ServiceNow or AWS Simple Notification Service (SNS).
3. The AWS SNS service triggers the workflow automation and launches the AWS Lambda auto-remediation
function.
4. Using the AWS API, auto-remediate and fix the offending issue.
5. Send the resulting logs to AWS CloudWatch.