I want a SNOC, a SNOC is all I want
The following blog post has a portion of sarcasm, or it has a huge portion of truth hidden in sarcasm, you decide…
I think when we imagined the SOC we did something terribly wrong. Our mistake was that we created an standalone thing which should be the ruler of all things Security Operations, but we hardly ever really followed through with that and ended up creating a monitoring organisation which is hardly able to take action.
In the early 2000’s I have been a system administrator. There wasn’t really a SOC back than. That doesn’t mean we didn’t do security. We handled our PCI-DSS compliance, we monitored the system logs for strange findings, we patched our systems (I actually patched Gentoo systems, kind of a nightmare), filtered email… well you get the idea.
Bottom line, we did not have a SOC and still performed Security Operations. Suddenly, SOC’s became a thing. But it was a half hearted approach, in my humble opinion. As the SOC took our logs, not all of them of course, the SOC is kinda picky, which makes sense, right(?), as they don’t understand the baseline of the system, or the things we, the NOC, have done to keep this company running through the growth of systems, the ddos attacks and the old code on old systems who’s creator left years ago.
As a result, well, we never handed over our infrastructure. Yes, Firewalls are for security, but also for our network segregation. Also email filtering and security gateways are great for monitoring malicious emails, but first of all we set them up so our company can receive emails. We couldn’t just give the keys to the network to some random dudes. Dudes which mastered in a field which did not even existed when we builded those systems.
Dudes who also never understood that an API should act between two thresholds. The lower threshold is when we start making money. Our shop systems can not live on 2 API calls per hour, even worse when it is zero, cause then the salary at the end of month is at risk, but also every count above x basically will be too much for the backend system to handle. The NOC knows this sweetspot, and Nagios will go crazy if something is out of the norm here.
Also, although your ISC2 certification tells you otherwise, uptime was never a concern of the SOC… yes… yes … yes… we know you send us rude messages if you don’t receive security log files for 24h. Also I know that it is hard for you to spot a ddos attack if there is no system in place which tells you that black on white. You know that our Nagios actually could tell you if the amount of connections goes up? Genius right… it does so since 2002.
I never understood why we never created a SNOC (Security and Network Operation Center). Well I understand that the billion dollar market of Security Intelligence Operations and Consulting Services, SOC transformation, Security Consulting and such would not have been a thing, but I mean real reasons.
But, we separated something which should have joined forces in the first place. Instead of patching systems, we (still the NOC) waited for the SOC to run a half good security scan and tell us which systems to patch.
Instead of the people coming to us cause something smelt funny on their machine, the talked to the SOC, so that the SOC could delay the solution for some hours just to end up with one of our guys going there and fixing it.
There should have been a SNOC. Using the SIEM and tools like Nagios. Taking the baseline the NOC already knows instead of dragging us into meetings where they tried to understand why there is a natural limit of ±65000 files in a Linux folder or why it is a bad idea to fill iptables with hundreds of thousands of bad IP addresses.
DevSecOps was a great idea. Years too late, but a great idea, you need to get Security into the cycle of your normal operation, not create something which is totally apart and needs the help of all the others to survive…
Leave a 👏 or fight me in the comments 🙂
Like always, be excellent to each other