Unlike firewalls, which dispatch traffic on the first positive match, packets processed through IDP can fall through the rule base and be processed multiple times. But we were able to set rules as terminal, meaning once the rule matched, the action--be it "none," "drop packet," "drop sessions" or "send reset"--would be taken and processing would stop. Order matters and is intuitive.
We did have to add some signatures to the rule base to allow certain kinds of traffic. For example, as we noted earlier, IDP doesn't recognize the STARTTLS command within SMTP, which is used to start TLS for traffic encryption. Every time a TLS-enabled MTA (Message Transfer Agent) or MUA (Mail User Agent) negotiated with the mail server, an alert for a bad command would trigger, and subsequent SMTP packets would be alerted as having binary data in the header. We created a signature that looked for STARTTLS using a regular expression and then ignored the flow that resulted.
Unlike IntruShield's, IDP's signatures are viewable and editable. For example, the smaller IDP 10 product, which we included in our live network testing, kept alerting on HTTP traffic between IntruShield Manager and the laptop running the IntruShield management client. The signature was looking for binary data in the entire TCP payload and triggering. We located the signature and changed it to match only HTTP packets with binary data in the header portion. This edit ability let us easily refine the signatures so that they conformed to our normal traffic. Of course, we would never be cavalier about editing signatures because we know we could just as easily render them useless. But used wisely, NetScreen's signature editing is a powerful capability and a clear advantage over Network Associates' closed signature model.
Reporting Miasma
Although there are lots of things to like about IDP, alert viewing and reporting aren't among them. When we knew exactly what we were looking for, such as specific attacks, ports or hosts, we could define filters in the real-time alert viewer that narrowed the information flow to a manageable level. These filters could be assigned to views so that they could be reused, and the real-time alert viewer provided a filterable log of all events processed. Double-clicking on an event brought up a detail dialog box, which provided a brief description of the event and any applicable references. Right-clicking on the event brought up a context-sensitive menu with options, such as Filter, Show Data and Locate Attack in the attack objects or policy. The Filter options could filter on the column field selected, and subsequent uses of the filter narrowed the data further. For example, we were troubleshooting a POP3 issue, so we filtered first on the POP3 Command-Failed alerts, and then filtered those results by the host we were interested in.
To realize the benefits of cloud-native software, an application must actually be cloud-native—designed to run in the cloud, interacting with disaggregated cloud services, fully manageable as code—to deliver the expected benefits.
By combining resources and expertise, the AI-Enabled ICT Workforce Consortium will offer a blueprint for how industries can adapt to an AI-dominated future.
IT leaders should heed the guidance of cybersecurity insurance providers who think businesses should prioritize security education, incident preparedness, regular internal audits, and ongoing vulnerability scanning and patching.
