Besides the visibility that I have mentioned about my use case with Akamai Guardicore Segmentation, we can also create rules. If we think that one specific namespace should not communicate with another namespace, we are able to create rules on Guardicore to avoid that communication, or not necessarily only from one namespace to the other, but from one specific port from the source to one specific port to the target, so we can also build those types of rules, and that really helps improve security for customers.In general, I would say that the best features that Akamai Guardicore Segmentation offers include visibility and the ability to have Layer 7 visibility, which means that we are not only looking for source IPs and ports and target source target IPs and ports, but we are also looking for services. We are able to see even the service that we can create rules for, allowing from server A one specific service to communicate with server B, but if some other service tries to do that communication, it will be blocked, making that a great feature of Guardicore segmentation. There is also the deception model they have, which is the Honeypot model. Once we have one rule that is blocked for some specific ports, we can intercept an insider threat that tries to do RDP to one server that should not happen. With the deception model, that communication is blocked, and the insider is sent to a Honeypot server where they think they have established that communication and may try to add some script there. Guardicore adds logs and creates an incident, so we can see what that communication has done and how someone tried to compromise the environment. After implementing Akamai Guardicore Segmentation, I can say that for most customers with whom we implement Guardicore, we see once we do micro-segmentation for an application that the connection—possible connections that can be established on that application—usually drops by 80%. If we map out the proper communications that one application should have and create rules to apply the proper blocking, we see one application that could have a hundred thousand different types of communications, and after micro-segmentation, it can have only twenty thousand, thereby significantly increasing the security posture. In day-to-day operations, we usually don't have any impact, which is the idea of Guardicore. Once we have the rules in place, we only allow the communication that is supposed to happen. This is why we increase the security posture, but we don't impact applications usability and anything else. For day-to-day operation and risk management, as I have mentioned, we typically reduce the communications that we can have with a specific application, so if a customer's environment is compromised, usually we can guarantee that with Guardicore segmentation, if we have the proper rules in place, other applications will not be compromised, and the communication will stay only inside that specific application.