Originally from my blog
“Why? How?” It is very often the questions that follow when I tell people I basically built two new jobs for myself at my current company, after being originally hired for a third one. In the last five years, my path went from a developer to a system administrator to a security practitioner, two of those jobs built from scratch. My usual answers to “Why? How?” are mostly, necessity and passion, which are not that interesting. But sometimes people go from there into, “What did you learn? How did you do it?” To me those are way more interesting question. They allow me to share what will hopefully be insightful or helpful tips with the person I’m talking to. And now I’m sharing those same tips with you, hopefully with similar results.
Processes, commands, ideas, research, etc. all those should be documented for yourself or your teams in the future. Everyone keeps saying how important documentation is and while I believed them I never took the time to actually sit down to do so. You will always have other priorities waiting for you and emergencies or customers to help. Many times I’ve had to sit there on the phone with a customer, stressing about the exact version of the command I had to do in their system. It’s never enjoyable to have to rack your brain trying to remember what you did for them six months or even a year ago.
But if you streamline the documentation and process writing, it doesn’t have to take long. That documentation will also prevent future emergencies and time lost, I do not want any of those stressful phone calls anymore. Sometimes I just use a plain text note and sometimes a note app to write the main points while I work. Then I expand on them later (in the same week preferably) but I always try to take notes, especially related to customer things.
There will most likely be some hard decisions you will have to make, especially about changing jobs. When you reach those points, you should think about saying “yes” as your first answer, especially if you have the backing of your company.
When I first went from programmers to a system administrator, I didn’t have any school or official background in that field. I did know how to do it from my own tinkering, experience and my personal servers. Fast forward today, we’re a 60+ customer business in a field that has a limited number of possible customers. We also now offer a variety of integration with customers systems, some of which I built myself. All of these things happened because I said yes. I will not lie, I was afraid at first and it was definitely hard on me to get here. Ultimately, though, that’s what allows me today to say, you should start with “yes” and see from there.
Do not be afraid to shout about things you see will break in the future. But when you do, be sure you’re ready to back it up with facts. Also, if your company is anything like mine, you might end up having to fix it.
That is basically how I became the company security practitioner. For years, I shouted at various managers how we needed security practices and processes. Before that we were mostly using common sense and logic, which can work as you slowly grow. When you reach a certain size, however, in employees and customers, you need more. That’s the point I saw in our future, I was seeing things breaking in our processes as I went. Often employees in the field or even a related field will be the ones who spot things that could lead to more problems. But if no one plants a red flag about it, they most likely won’t be seen until they’re actually broken.
This one applies a lot more to startups and smaller companies, where you have to get things out now. Often you won’t even have time to make it great, you will just have enough time to make it good enough. That’s OK, it’s how things go, the important part here is to make sure to make a note of it for yourself and your team. The important points to note are what needs to be changed and why. Then in a few weeks/months/years that system will most likely break or have to be upgraded again. This time if you have a document saying what it needs, you have a starting point. That document is also a way to ask for enough time this time around. On the other hand, if it does break because of things you missed, you have a trace of where to start. In all likelihood it won’t impact your reputation since you have proof that you thought of it but constraints prevented you.
Well, I gotta start somewhere. I will most likely write a lot more of those, as time goes on and as I keep mastering those jobs. Three jobs is enough for me, but security is a very large field with still lots of things for me to discover. There are also new technologies and solutions coming out all the time for better system administration. Those things are also on top of things like hiring and building a team when you reach the point of not being able to do everything yourself.