03. 09. 2019 Massimo Giaimo Events, Log-SIEM, NetEye, Service Management

NetEye SIEM: The Attacker’s Point of View

In our ethical hacking activities there are three different phases in which we clash with the themes of SIEM:

PLANNING – The phase prior to the activity where we define the scope of engagement, be it for a Vulnerability Assessment, a Penetration Test or simulating a real attack
CHALLENGE – The activity, corresponding to Vulnerability Assessment (VA) or Vulnerability Assessment and Penetration Testing (VAPT)
EVALUATION – The phase following the activity, which often coincides with the presentation of the report

In these three phases SIEM is, respectively, an element of planning, an element of challenge, and an element of evaluation.

In the phase prior to the challenge phase, and in a White Box scenario, we usually listen to the reason why a company decided to acquire a certain product to manage their corporate security, and why they chose one vendor over another (e.g., costs, localized support, pre-sales skills, etc.) Again and again, IT managers try to tell us “You’ll see that it won’t be so easy to make your attack attempts invisible to our probe”. Whenever we hear these words, we always have a little hope that our interlocutor will actually say this from their own direct experience, not from hearsay or because he or she has been convinced of this by the vendor.

The fact is that when we find out, either directly from the interlocutor or during the information gathering/scanning phase, of the existence of this type of device in the infrastructure being tested, our Red Team makes some changes with respect to the standard procedure, entering into stealth mode.

From the ethical hacking point of view, it means making as little noise as possible within the infrastructure, in such a way as to reduce to a minimum the possibility of making any attempts at attack evident. From a practical point of view, this involves the use of highly precise timing to perform scanning activities and the use of lightweight payloads during exploit activities.

This level of attention does not always (obligatorily) reflect a real need, as more than once we have had to deal with probes either implemented in an inappropriate way, or with a configuration “copy & pasted” into the customer’s infrastructure. One can only assume that the consultant was certain that a perfectly functioning configuration within a previously managed infrastructure would also be suitable in a new one. This is an incorrect (and dangerous!) method for installing these objects.

Think Like an Attacker

For a long time we have tried to convey the idea that every organization – even from the point of view of information security – needs to be managed in a unique way. The level of security is an element that is constantly being re-evaluated and depends on many aspects: the people, technology, operating methods and the surrounding environment. What organization can categorically and reasonably claim to have all these elements exactly the same as another organization?

Another element that we have tried to disseminate is the importance of the attacker’s point of view. At the moment when a cyber-criminal is planning an attack against a target (perhaps instigated by a competitor), their first activity will be to search for as much information as possible about the target itself. This activity, commonly called Information Gathering, is one in which the attacker will invest the most time and resources, because he will be the one who can make the difference between an attack’s success or failure.

Why can’t a company anticipate this activity on its own, or delegate it to third parties? The elements that need to be identified are: what information is most appealing, any potential attack vectors, an attacker’s motivations, and which areas are vulnerable. Unfortunately this rarely happens, first of all because it is difficult to find experts in-house with the knowledge, point of view and sensitivity necessary to identify these elements. Furthermore, in various areas, security is still seen as a cost rather than an investment. And that is why rather trivial and devious attacks continue to succeed, due to a company’s presumption of having already implemented an excellent defense strategy, or simply because there is no knowledge of what the attack vectors might be.

Our Red Team’s activity becomes fundamental to studying infrastructure weaknesses because it is carried out independently and because it allows an organization to question preconceived notions, reaching a greater understanding of the security problems that must be mitigated, as well as highlighting potentially compromising sensitive information, bias and patterns.

Monitoring and Security: Two Sides of the Same Coin

Let’s return to the question of the probes that some companies have bought hoping to solve once and for all the age-old problem of IT security. We are disappointed to note that during our attack simulations, in many circumstances these probes have been unable to detect attacks. And where they did notice something strange happening inside a company’s infrastructure, they identified aspects that, rather than helping the internal IT department identify the threat, instead dangerously throw everything into confusion. (For example, why should you bother to detect that someone within the network is viewing the website as if conducting pentest activities, while completely ignoring the much more common vulnerability to a cross-site scripting attack?)

Having had to deal with these dynamics daily, and personally confronting the disappointment (and even the anger towards the supplier/consultant) of those who have invested heavily both in time and money in these objects, we took the liberty of sharing these concepts with the engineers at Würth Phoenix, describing our concerns to them about the methods used by various vendors who then propose and implement SIEM solutions. From Würth Phoenix we received enthusiastic feedback, especially with an eye to understanding that a tool like NetEye Security Information and Event Management (SIEM) can only benefit from these same concepts.

A differentiating element in the solution proposed by Würth Phoenix (and that potentially, from my point of view, can transform the solution into a reference points in its field) is without a doubt that of uniting, within the same product, both the classic aspects of an IT operations monitoring platform (with more than a decade of experience gained from the solution in this field) and those of Security Information & Event Management. Being able to observe these two aspects from a single point of view allows the security analyst (or whoever needs to intervene in order to analyze a specific accident or violation scenario) to see his work greatly simplified and decrease the time necessary to identify the different elements present in the scenario’s perimeter of observation.

We became aware of this the moment we started working with NetEye SIEM, because it is able to generate an alert in the face of a detected event, and possibly link that alert to an already existing host for which we are already monitoring certain metrics (e.g., CPU load, I/O traffic, network interface traffic, etc.) Thus instead of going to generate an alert for its own sake (as happens in a typical SIEM “standalone” platform), it becomes an element of enormous value. This is an obvious aspect for those who manage systems, because an attack very often leads to a significant change in the values of the metrics listed above.

What data should you send to SIEM?

One of the questions we increasingly receive is, “Which data sources should I integrate into a SIEM platform, and with what priority?” The only sensible answer that can be given in these cases is “It depends on your monitoring needs and on the use cases you think may be most useful.” The next question then becomes, “Ok, what are my use cases?” And it is at this moment that the consultant must bring out the best in himself and professionally study the organization’s perimeter, both internal and external, in order to perfectly and precisely identify the elements mentioned above (more appealing information, attack vectors, attacker motivations, areas of vulnerability, etc.). This is a highly complex activity, because it forces the consultant to think outside the box, trying to duplicate the thoughts a cyber-criminal would have when planning an attack.

A fundamental source of assistance within NetEye SIEM surely stems from the possibility of integrating the outstanding work already done by the Sigma project developers, who have surveyed hundreds of signatures of different types of attacks, and made them available to the entire security community.

We are so passionate about the Sigma project that we even decided to make our own contribution to it, writing precise rules for detecting the attacks that we often carry out during our simulations. Certainly, in the phase evaluating which data sources must be integrated into SIEM, one relevant aspect is the economic component, since most SIEMs have a licensing mode for gigabytes/day or EPS (Events Per Second).

And so should we use as a data source the logs produced, for example, by the DHCP or DNS server, which may use 5-10% of the license volume but will be used to write few or no attacks detection rules? Perhaps it’s better to focus on the source of data generated by the Intrusion Detection / Prevention System or the WAF (Web Application Firewall)? Again the answer is: it depends on the context.

Fortunately, the NetEye SIEM solution meets us halfway, allowing us to limit ourselves only to that data that is strictly necessary (using for example the filters that can be activated inside Elasticsearch Beats and other Data Shipping components present in the solution). Let me explain: it is not necessary to send the entire log generated by a DHCP or DNS server, but only those log messages useful to detect an attack. Clearly this implies a profound knowledge on the part of the consultant about which attack scenarios can be implemented for a particular protocol. The same applies to the logs generated by any existing EDR (Endpoint Detection & Response) systems, for which it will be advisable to filter the “critical” alerts.

Unfortunately (or fortunately) there is currently no SIEM capable of self-configuration. Of course, some “default” scenarios can be implemented out of the box for different organizations, but this is not enough.

A few years ago, a security researcher described the difference between an automatic vulnerability detection tool and a complete manual penetration test, saying that “the (automatic) application security testing tools can tell you something about security: namely, that you’re in deep trouble.” The added value in a SIEM solution must necessarily be the flexibility and complete customization of each parameter. Both aspects are present in Würth Phoenix’s NetEye. And when configured with the correct tuning, it can allow you to alert those responsible before the trouble piles up that deeply!

If you would like to get more insights about this topic, you can meet me at the NetEye User Group on November 6^th, the event especially organized for all Würth Phoenix customers that will take place in the Ferrari Museum in Maranello – you can register now from this link.

Don’t miss my keynote talk: “The Secrets of an Ideal Asset – SIEM as the Answer to Cybersecurity Events”.

>> Read the Italian article in its original language (PDF)Download