If you have children, you have for sure already faced the following situation just after they messed up. Oh, the joy of seeing them denouncing and pointing at each other with classic expressions like “It’s not me, it’s him!“. Of course, you did not see what happened and children do not generate logs. How to react in such situation? Who will be punished? This blog is not dedicated to parents, I let child psychiatrist debate on this topic…
But this small introduction could be transposed to (our best friends) the security vendors. The following facts are of course based on a true story but “the names have be changed to protect the innocent“. A $organization is using firewalls provided by $vendor1. Because they have strong security requirements, they deployed a SIEM solution provided by $vendor2. And a first problem already popped up! The firewall object names are defined at firewall level and not based on DNS. To permit the SIEM to do it’s job, the resolution of object names has been disabled in the firewall. As says Kris Buytaert: “Everything is a freaking DNS problem!“.
But recently, they installed a new tool to manage their firewalls from a central console (policy analysis, administrative tasks automation, compliance checks, etc). This solution is provided by $vendor3. Guess what? This tool requires object names in logs to correctly process them. All vendors were of course contacted, tickets opened. But the feedback was always the same: “That’s the way our product works!” (Read: “It’s not me, it’s him!“). Do you see the relation with the children now?
Who is to blame? The vendors? The organization? They are several points to mention:
- The organization could create object names which are resolvable via DNS. This will make all products working together but it could have a huge impact on the DNS server used by the SIEM to resolve all the object names (especially if the firewalls produce lot of events).
- The firewall vendor could change its event format and include the object names and the IP addresses at the same time. I’m also thinking about IP addresses behind NAT. More verbose are your logs, more you could extract useful information.
- The firewall analysis tool could perform a lookup in the firewall objects database to resolve the IP addresses itself. After all, if they can alter the policy (write access), they could extract this information.
I won’t blame one or another here. My point of view is to keep the security at the highest level. Situations like this one can lead to the discontinuation of projects. Big investments in time and money are made and finally the solution will remain under-used or, worse, not used at all. A side effect of security could be the introduction of more complexity. You need to fulfill compliance requirements or you need extended controls? Don’t just simply deploy a new toy solution. Most vendors will tell you that their solutions are installed in a few click with nice wizard. True! But do not underestimate the integration in your existing environment… Make proof-of-concepts, test the solutions in deep, ask for other users feedback!