We invited Argus Systems Group, Armored Server, Computer Associates, Entercept Security Technologies, Harris Corp., Network-1, Okena, Tiny Software, Tivoli and WatchGuard to participate in our tests of HIP products. Tiny Software was unable to get us a product in time. Network-1 said it didn't have a product fitting our criteria and Tivoli just refused to come play in our sandbox.
That left Argus' PitBull LX and Protector, CA's eTrust Access Control, Entercept's Web Server Edition, Harris' STAT Neutralizer, Okena's StormWatch and StormFront, and WatchGuard's ServerLock and AppLock/Web for testing in our Syracuse University Real-World Labs®.
These products run the gamut from all-encompassing systems--such as CA's Access Control, Harris' STAT Neutralizer and Okena's StormWatch, that protect a wide range of applications--to products like Argus PitBull Protector and WatchGuard AppLock/Web that are targeted at Web server protection.
All the products install as kernel-level modules, or in the case of Argus PitBull LX on Solaris, as a kernel and shared library replacement, to trap or modify system calls. The products process the access requests via policy engines before passing them on to the system for execution. Access requests that are denied never get to the underlying operating system; the server hums along unaffected and the attack becomes water under the bridge.
Although we expected different types of configuration options depending on OSs supported, we were surprised to find disparities such as those in CA Access Control, in which you can limit the actions servers are allowed to take on Unix but not on Microsoft Windows 2000, or in Argus PitBull Protector, which is highly configurable on Unix, but not on Windows 2000. A few products, including Entercept, Argus PitBull LX and CA Access Control, allowed user-based access-control rules that let us create policies specifying which users can write or update files while blocking all other writing.
Our ideal product would let us centrally manage and enforce a host-security policy that limits access to only those system resources required to run the application. For example, Web servers need to read configuration files or registry keys, read documents from the webroot, execute scripts from a cgi-bin directory, and bind to Ports 80 and 443. You should be able to block the ability to overwrite or modify critical OS files except where necessary for normal system operation, a block all the products we tested allowed.
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.
