How A SIEM Keeps Watch, Like Big Brother, But Over Your Network – Conclusion
Last week, we talked about the need for a SIEM amidst today’s ever-shifting digital landscape. And that while it is a pivotal piece of your cybersecurity roadmap (or should be, if it isn’t yet), the SIEM is by no means a new concept.
And the importance it plays in your strategy?
Well, that’s about to ramp up. Why? Because, as security experts acknowledge that the perimeter is open, the importance of monitoring the “LAN” has just skyrocketed. No longer can we ignore those potential alerts hailing from the internal IDS. Or all that data written in Active Directory logs. As breaches occur, most times we realize that had we looked at the data before, chances are we could’ve discovered said breach much sooner. Perhaps even prevent it.
Technology too is extending a big ole helping hand. The advent of the cloud allows accumulation of enormous amounts of data for analysis. Without the need to acquire and install correspondingly massive computers. New forms of databases, which mimic the structure of Google’s Internet indexes, are commercially available as well. This allows for much faster searches on very large numbers of records. Note that this was something impossible to achieve with SQL databases, no matter how large the hardware was.
We’ve also learned how to write rules that correlate with the events we collect. And with the information we’re storing. Big data analytics and machine learning are buzzwords, yes. But those technologies really did come in handy when applied to the SIEM.
The convergence of all this hardware and software technology has allowed the appearance of a new generation of SIEM on the market. One that is truly a much more evolved form of its original, remote cousin.
In the meantime, many regulatory bodies have started to request the logs be retained for a long time,. They’ve also started to define which logs. And banking regulators are now asking logs to be retained for at least 1 year. PCI requires 7 years. And there are plenty of other regulations, that in a way or another touch everybody, all requiring long term log retention. And all of them also require offsite back up of such logs.
Enter the Network Box SIEM+. Or, as we call it, NWB SIEM+.
Why +?
Because one of the major obstacles to the large diffusion of SIEM so far has been the enormous difficulty in implementing and managing such a tool. Countering this, our offering is completely managed, as always. Entirely hands-off for clients, making their experience comfortable. Smooth from start to finish.
Another thing. Our SIEM is fully cloud-based.
Today it’s hosted in the AWS cloud but this is only today’s choice, and certainly something that could change. The important factor here is that there’s no need for ‘offsite backup’ since ours is already offsite. Deploying only the most modern technologies available to ensure fast queries over vast amounts of data. It comes with a large set of pre-configured rules, yes. But these are easily customizable for each client’s needs. Data is kept inline, on warm storage, for at least 90 days. After which it’s moved to cold storage for longterm retention and regulatory compliance (cold storage is much more cost efficient option than warm storage).
However, we’ve never been good at being followers, preferring instead the role of leader. Of innovator. And so, we’ve improved the legacy approach to SIEM by introducing a new concept. Changing the meaning of the I in SIEM. No more Security Information, but rather Security Incident.
Why Incident?
Because simply having the “information” of what’s transpiring isn’t enough. No, it leaves a lot of guesswork for you to decipher if something’s going on. Our system (and our SIEM engineers, when the need arises) does that for you. It does that by means of specific, customizable rules that analyze events, correlate them, and raise alerts when rules are met. In other words, they raise incidents.
What do you do with these alerts?
That depends.
Joe just gained Admin access to AD. Was this a desired action? Based on your response thereto, we either correct the rule or ignore the alert. If it was neither an anticipated nor wanted action? That triggers an investigation into whether it was a breach or an internal threat of some kind. Clearly, I can write pages and pages of such examples but I shan’t. Suffice to say, anything that happens and looks suspicious will be treated as such, and will raise an incident. What you do with that, is entirely up to you. But rest assured that we’re here to provide you with the tools to take quick action in correcting (or even preventing) problems.
Need help?