Late 2020, second wave of covid, red zones, everybody at home. I was working from my kitchen, and between scheduling a few batch jobs, configuring the phone system and watching the monitoring, there was very little to do. So I used the time. I paid, out of my own pocket, for two security courses: CompTIA Security+ and CEH. I never sat either exam. This is what the training was worth on its own.
I paid for them myself because security was out of scope at the company. Nobody had said no; it simply wasn’t part of anyone’s job. The lessons were recorded, which cost some interactivity but worked fine, and I followed them during working hours, between one task and the next.
Then smart working ended and I went back to the office. I told my managers about the courses and got a different conversation than I expected: the infrastructure was going to be dismantled and moved to the hosting provider of the group, so I would be needed less as a sysadmin and more as a developer on the platform. I said yes, I’ll sign up for the exams, they cost a bit but I want to try. I never did.
I still have no Security+ and no CEH. This post is about what the courses were worth anyway.
What I expected, and what I got
I expected to become a certified ethical hacker: one of the good guys who protect companies from the black hats. That wish is older than the course. It goes back to Windows 95 and mIRC, and to technical school, where I had fun with computers because I knew them better than the teachers and the school’s technicians did. Even back then I wasn’t asking how a system was meant to work, but how it could be made to do something else, and I learned early that the weak point is often a person, not a machine. It became my mantra when I read Kevin Mitnick’s The Art of Deception: look for the weak points, which are usually people.
The course was supposed to turn that old itch into a respectable job title. That didn’t happen, and I’m not complaining. I got something else.
Security+ gave me a large amount of material on security and governance: the vocabulary, the controls, the way an organisation is supposed to think about risk. CEH gave me a different way of reasoning about security, which I’ll come back to. Neither made me a hacker. Both gave me a map of a territory I had been walking through for years without one.
Five years of sysadmin, almost no security
By then I had about five years of sysadmin work behind me. Plenty of operations, very little security and compliance.
My routine was the usual one. I configured the server, got the service running, and then, when I had spare time, I made it secure the way I thought it should be. “When I had spare time” is the whole problem in that sentence. Spare time doesn’t arrive on a schedule, so the hardening arrived late, or in part, or not at all. I wasn’t careless: the order was wrong. Security came after the work, and the work never stopped.
What the courses gave me was not a new technique for any of that. It was the idea that the order itself was the mistake.
Security first, then everything else
Today the order is reversed. I create the server, apply a documented hardening procedure, and verify it immediately. Only when the server is safe do the CI/CD configurations start, and those carry their own security practices for the applications: permissions, patches, separation between users.
The same procedure applies from the most critical machine down to a shared web server where nothing much happens if it goes down. I manage in the order of 50 VMs this way. A less important server doesn’t get a lighter procedure, because the risk of a forgotten box is never about how important it is.
After that, two things keep running. Vulnerability assessments on a regular schedule, so a server that was fine at creation gets looked at again. And active threat monitoring, so I’m not relying on the assessment to catch what happens between two runs.
The difference in time is the part I like most. Before, “making it secure” took days or weeks, whenever I found the time. Now it’s part of creating the server, and a server that isn’t hardened and verified doesn’t go into use.
Thinking like the attacker
The CEH gave me a question that I now ask about every server: what would I do to get into this one and use it for something it was never meant for?
That’s different from “is this configured correctly?”. A checklist tells you whether a setting is on. The attacker’s question makes you look at the server from outside, the way a stranger with a scanner would, and ask what it tells him about itself before he has done anything. Then you remove what doesn’t need to be said. Around that sits the classic perimeter, a firewall, which everybody has. The part that came from the course is the habit of reading my own servers as someone who wants something from them.
I won’t list what I change or what I hide: that’s the kind of detail that serves an attacker more than a reader. What matters is the question, and that I never asked it before the course. For five years I had asked whether things worked. After the course I asked how they would be abused.
The audit that made old servers a problem
Not everything was built after the courses. Some of the old web servers were configured before, with the old order: working first, secure later. The first audit put them under the spotlight.
The problem was exposure. All the PHP sites ran under the same user, with no isolation between them. If one of them was compromised, the others sat right next to it with the same permissions.
The fix was simple: PHP-FPM, one pool per site, each with its own user. I first moved every site to the default pool, then gave each one its own, with permissions on its files and directories. It took a quiet morning and wasn’t painful at all.
I’m not telling this to look good. I’m telling it because it shows what the new order prevents. A server created today with the hardening first can’t end up in that state, because the isolation is part of the procedure from the start.
ISO 27001: practice over theory
When the company went for ISO 27001, I followed the certification myself. The management system is small: me, someone from management, someone for the business processes, and an external consultant.
Going through the Annex A controls, I found almost every best practice I had learned in Security+. The course had given me the vocabulary, so the standard didn’t read like a foreign language.
The one place we went our own way was risk assessment. The most widespread method in Italy is a matrix that combines a long list of factors into one number. We chose not to use it: it would have become hell to manage. We built our own, based on the information we handle: the impact on confidentiality, integrity and availability, multiplied by the likelihood, giving a score. The bands of the score say when action is required and when monitoring is enough. Less theory, more practice, few rules applied properly.
It worked. The auditor liked it, and the next surveillance audit is already scheduled.
What a certificate doesn’t tell you
The piece of paper matters. It signals that you have studied and met a defined standard, it opens doors, and a client or an auditor who doesn’t know you has nothing else to go on. I don’t have it, and I won’t pretend that doesn’t cost anything. I may take the exams one day, I haven’t decided, and I’ll keep taking the courses I think I need.
But I’ve learned to tell what the paper does and doesn’t show. Theory is good, and it makes you recognisable as someone who studied. It doesn’t show how you behave when something breaks. Every time I’ve argued a technical point with someone certified or with a degree, I’ve had to explain my reasoning first, and then my solution turned out to be the right one. That is my experience, not a rule, and I’m sure plenty of certified people would win the same argument.
What worries me when I think about hiring is the person who has the badge and has only worked in a lab. At the first real moment of panic they can make things worse. Or they apply a solution that is overhead for the reality it’s meant for: a heavy method, a heavy tool, built for a much bigger company. That is the same lesson as the ISO risk matrix: a method nobody can run is worse than a simple one that’s applied properly. I wrote about the other side of this in fixing PCs and the attitude it gives you.
Is a CEH or Security+ course worth it without the exam?
Yes, if your goal is knowledge. For me it was a map of the territory, a new way of asking questions about my own servers, and a vocabulary that made ISO 27001 readable. No, if your goal is the credential: without the exam you have nothing to show to someone who doesn’t know you, and that is a real cost.
What I’d take from this
- Do the security before the work, not when time is left over: time is never left over.
- Ask what an attacker would do with each server, not only whether it’s configured correctly.
- Few rules applied properly beat a perfect method nobody uses.
- Keep the same procedure for the important server and the one that doesn’t matter.
- A certificate opens the door; in the interview, dig until you know what’s behind it.
- A course you pay for yourself is worth something even if you never sit the exam.