Continuing with my research I see that Security “concerns” (although not *requirements*) may be present in the Erlang literature, but in such a way that whatever is said about Security remains in the periphery and ultimately disappears from view. This happens even in cases where (as we will see below) the subject addressed seems to be related to Security.
The text “Embarking on the road of Intrusion Detection with Erlang” by I.A.Letia and D.A.Marian, dated May 27 2010 (10th International Conference on Development and Application Systems) is outwardly focused on Security, i.e. on fairly central area of security technologies related to network protection. Intrusion detection is a well-established part of the Security specialties and also an obligatory part of any IT infrastructure.
The authors begin their work with some standard definitions and a summary of the intrusion detection area, to move later into those functionalities that make Erlang a good candidate for the implementation of an intrusion detection system (IDS). The first part of the paper (What Erlang Provides for Intrusion Detection) is a summary of the characteristics of Erlang-OTP and perhaps useful for students of the language.
The second part of the paper tends to define intrusion detection in terms of network traffic and host monitoring, and this guides the rest of the work. In fact, Letia and Marian have developed what can be described as a monitoring tool and a set of distributed monitors for host and network log files and standard operating system tools. The authors have chosen a “white list” approach to intrusion detection, i.e. one where you need to “learn” the “good” state of a network so to be able to discern what can be flagged as an attack.
Regrettably, the paper does not explain (or at least I don’t see where the explanation is) what can be considered a safe state of the network and especially not how the data is stored and analysed. It is also not clear if the analysis is in real time or not. All of which frankly reduces the interest of this paper. For example, if the proposed system depends on syslog messages that have been emitted due to a “violation of a security policy” in a firewall, this presupposes that the security policies and the firewall rules are actually covering already a meaningful span of the attack surface and hence the proposed system is just some form of aggregator of the available information.
Clearly Erlang would have been more appropriately exploited in this case if it had been used to build “intelligence” into the detection process by means of a rule engine.
An excessive engineering focus on what “can be done” with Erlang, occludes the question about what “should be done” –if at all!
Now, for me, while reading this information what became more (akwardly) interesting were two paragraphs in the text that were related to Security “concerns,” both of which nevertheless do not lead to any conclusions in the paper. The first comes towards the beginning of the third page, where the authors are describing the behaviour of their monitoring sensors, where they say: “Observations might incur a security and a privacy risk since making observations sometimes requires administrative privileges. It is one thing to run an application with administrative privileges on user’s workstation, and a different thing to run it on the network’s gateway. In the hands of an attacker the required observations might show the vulnerable points and five the means of attacking the network of the common users. If these observations are sent to a remote site for processing, this risk is further enhanced.”
While the authors recognise the Security problem here, nothing is made of it. But we are able to see that the “risk” described stems from the fact that their “application” (the Erlang-based IDS) has no Security requirements and no protection of its own, so that the tool itself is insecure even when its functionality is directed towards “intrusion detection.” This would be less damaging if the authors had been focused on performance, code optimisation or any other aspect of application engineering, but the fact that they were working on a Security subject makes this gap more glaring. I have to ask myself: “What was the purpose of this paper?”
The problem is compounded later when the authors (correctly) state the following: “A group of Erlang nodes that share a common secret known as the cookie, form a trust group. Nodes in a trust group communicate, by default, using unencrypted message passing. Combined with the fact that a node can create processes, make Remote Procedure Calls (RPC) and execute foreign applications on a different node, in the same trust group, Erlang is rather insecure. Furthermore, functions are first class objects and can be sent across nodes, so if the security of an Erlang node is compromised then the entire group is under threat. The Machine module shows some built in functions (BIFs) for changing the trust group secret cookie and provides an insight on how Erlang could be used to collect relevant information from the observed computers.” (page 4)
So, in a few lines we confirm that the purported “intrusion detection” system completely depends on the Erlang capabilities and in addition to that we learn in 7 lines of text that Erlang is “rather insecure.” But this is certainly not true. It may be “correct” or even “useful” but it cannot be true.
The only thing that becomes clear is how disconnected these annotations are, how odd the Security concerns appear in a paper that supposedly is dedicated to Security.