Elemental claims it has a firedoor

As expected, recent newsletters on firewalls and what I’ve christened “firedoors” brought a rash of comments to my inbox. Most were of the “where can I find a firedoor?” variety typified by this response from a well-known Fortune 500 company: “I just have to tell you that my boss (Infrastructure Director reporting to the CIO) was really intrigued by the firedoor conversation. Our company has 170 locations; if one starts causing problems, it would be nice to be able to slam the firedoor on them to prevent the problem from spreading all over our company. We think that’s a pretty good idea.”

Well I think it’s a good idea, too. So the one response I got that wasn’t a plea for a product was, if anything, more interesting. Actually, I would have been surprised if I didn’t hear from Dan Spalding, who heads up corporate communications for Elemental Security (see “Elemental aims to make policy-based computing easier to implement and monitor”). What he said was: “Boy – quarantining, dynamic grouping and access controls, active internal (host) monitoring and automatic discovery and policy controls (not passive), anomaly detection, reporting and action, and shutting doors to access to pieces of the internal network – wow, that all sounds like things Elemental does. We agree; we haven’t seen anyone offering what Elemental does either!”

I asked Spalding to elaborate specifically on the points I suggested that a firedoor should have and the following is what he had to say, gathered from his colleagues at Elemental Security, but formulated by one of the more articulate PR guys around. To refresh your memory, what I asked a firedoor to do was to react to anomalous activity, activity that may be intended to harm the network or the organization, by creating an isolation area where all of the potentially malicious packets are quarantined. But quarantined by event – separate areas for each attempt to breach security. The firedoor would then respond to the potential threat by sending back apparently legitimate packets as expected. It would also alert security personnel and log actions (just as firewalls do) but would also begin the forensic process to trace the attack itself as well as its source.

According to Spalding: “A key component to any firedoor is anomaly detection and the resulting enforcement. Because of Elemental’s policy-based, host-level approach, it readily exposes usage anomalies in terms of network activity for a host or group of hosts by reporting on traffic volumes for ports, protocols, and specified destinations (IP or URL/FQDN). In addition to network traffic, Elemental can also monitor the inventory of the hardware and software on a host.  Anomalies would be detected in the form of unapproved applications or hardware devices being found, such as [instant messaging] or removable data devices.”

Spalding also suggested that his product could “… respond to a potential threat by sending back apparently legitimate packets.” Because Elemental controls all inbound or outbound traffic based on policy and as long as there is an agent on either end of a network connection these policies can be enforced and the policies can control the traffic that is generated. 

In response to my suggestion that a firedoor should alert security personnel, log actions, and also begin the forensic process to trace the attack and its source, Spalding noted that Elemental gathers detailed statistics of managed and unmanaged machines’ traffic. “In the event of observed non-compliance or an enforced ACL that results in a dropped connection, Elemental reports on the details of the event, including the initiator of the unapproved communication. Alerts can be sent to the NOC via SNMP to alert operational staff of the potential security breach,” says Spalding.

Spalding even noted an anomaly I hadn’t thought of: tracking client/server relationships. ” Whether these are infrastructure services or application services, Elemental exposes changes in the number of servers or agents that are part of these communities. Also, trust is another anomalous activity detection capability. If a machine suddenly appears as a highly trusted host, it is an indicator of either a usage anomaly or a potentially serious misconfiguration error. In either case we expose something that would not otherwise be readily visible.”

I’ll leave it to you to decide if this is true “firedoor” functionality and if it would benefit your network. But it might be as close as we can get right now.