Ten years ago, in December 2012, I have officially started my career in the (Information) Security industry. During this period I have done pentesting, code reviews, architecture reviews, software engineering,reverse engineering, consultancy, secure design and probably many other things I cannot remember anymore. I am grateful for what I’ve learned but most important for the lovely people I have met and I’m still in contact with.
After these 10 years of experience, learnings and countless sessions I’ve spent working with my colleagues I thought I could do a small restrospective and give some advice to whoever wants to start this journey. Here are my top 10 recommendations for juniors, professionals and anyone willing to take a deep dive into Security.
Chose one field of expertise
Security is such a broad topic and you might lose yourself if you don’t specialize in a specific topic. Security is not only about technical details or risks. It’s about*information*, quality, people and yes, risks and technology. The principles of information Security can be applied almost in the same manner regardless of the domain you’re working in. Whether it’s application, network, physical Security, reverse engineering or ISMS(Information Security Management System) try to become an expert in that field you’ll benefit from it in other ones (also Focus on skills, rather than career paths)
Don’t fall into the CTF trap
I think pentesting is the most common entrypoint for Security enthusiasts to enter the InfoSec world. It takes time, skills but alsopractice to gain knowledge and master skills in a certain domain (e.g. application security). One way to do so is to participate in so called CTF (capture the flag) competitions usually held at Security conferences or solving small challanges (also called wargames).
While I think deliberate practice is the key to improve your skills and keep your attention where it’s mostly needed, I would not focus primarly on mastering these skills. Real professional experience is gained through real-world examples.
My problem with CTFs are the environment and the specific circumstances under which an attack can be successful. Unless you’re a Security researcher I would first go for the low-hanging fruits because these are the ones most attackers use to initially gain access to a system. At the same time I would still recommend reading CTF writeups as you learn (from an attackers perspective) how to deal with new technologies or how to exploit a common vulnerability in a rather exotic setup.
Deperimetrization is key
As recent hacks have shown (Uber) assuming you internal network is safe is just wrong. Once attackers have their foot in, they will be treated as normal users. For exactly this reason authentication and authorization for every operation is key to modern architecture. I hope more and more companies will adopt Zero Trust and Zero Trust Architecture (ZTA).
Security research is not daily business
Do you know this feeling when you’re at a Security conference, listening carefully to a talk and suddenly you realize you don’t really understand anything? It must be one of these talks where a super sophisticated attack (or a piece of malware) is presented to the audience from which only 2% really get it 🙈. It happens quite often that Security juniors attend these conferences and are super excited to do the same type of work (research) in their professional day-to-day life. But the reality is a different one and quite boring sometimes. Be prepared to understand business and developers requirements and help where needed. These requirements will differ a lot from what are you expected to do in an academic environment or as an (employed) researcher.
Don’t do Security. Enable it!
I saved this quote from Agile Application Security and I think it kind of summarizes how the perception of Security changed in the last decade. Security was often perceived as something that has to be proven (by checklists) and passed (in the sense of quality gates in SDLC ). However risks should not be evaluated once but continously. The role of Security is to ensure that concepts, risks, hacker mindests are included in the whole SDLC (requirements, design, coding, testing, implementation). Considering Security early on and throughout the process not only goes well with Agile but definitely contributes to a more sucessful end product. Be ready to talk to different stakeholders (developers, product managers, C-level etc.), at different stages instead of having a regular (every X months) checklist approach. Be proactive and share knowledge as much as you can.
IAM & SSO are fundamental
Information Security (InfoSec) defines certain assets (code, business logic, financial reports, employers etc.) to be protected from malicious activities with regards to CIA. Identifying who is doing what and assigning policies/permissions to different entities will enable granular access based on ACLs (Access Control Lists) and/or RBACs (Role Based Access Control). IAM (Identity and Access Management) will also allow you to impersonate other identies (in more AWS like language: assume other roles temporarly).
DevSecOps is more than a mindset
I consider this more than a mindset - I literally embrace it in my work with developers and operation folks. Being literally between SWE (software engineering) and operations you’ll have to take it seriously. This is indeed demanding and requires you to leave your comfort zone and learn about concepts far away from your home base. Once you take an*hollistic* approach to Security you’ll not only have discussions at same-eye level but expand your knowledge horizon for further career options.
ISMS is your friend
Early in my career I’ve decided to go for the the hands-on/technical path in Information Security. However, ISMS and compliance will give you the acceptance to implement security measures. Don’t be afraid of ISO 27001. As you cannot avoid laws and regulations, ISMS will provide you with the compliance framework needed to get things actually done.
Shift-left your radius of influence
As I’ve mentioned in Don’t do Security. Enable it! you have to expose yourself to lots of topics and work in a cross-functional position. You’ll talk to developers, DevOps engineers, product managers, engineering managers etc. All these people live within their own boundaries, talk a different “language” and have different opinions. That’s why you should
- learn about system design
- teach yourself about software architecture
- learn how software is delivered in an enterprise environment
Cloud Security is complex
I once read in Introduction to Cloud Security for InfoSec professionals:
“The cloud is software-defined everything.”
With the increasing adoption of IaC (Infrastructure as Code) everything becomes a resource mapped to an object in some code construct. Nowadays you can easily setup complex infrastructures, destroy them and redeploy again… just by running some code aka*software*! And as we know: Software is susceptible to vulnerabilities.
Running safe code is hard enough. But running safe infrastructure based on code might become a nightmare. That’s why Security professionals are often overwhelmed by the sheer complexity modern infrastructure creates. You have distributed systems, you have different actors (persons, machines, applications) accessing all kinds of resources, different programming languages / frameworks. All this is hard to understand in detail. For this reason embrace cloud-agnostic design patterns meant to protect your assets in-depth. Start with best pratices, setup a playground, learn about IAM (as IAM & SSO are fundamental), start little projects.
Focus on skills, rather than career paths
Last but not least embrace learning as a life philosophy. Learn a new programming language, be passionate about technology, make yourself familiar with a new cloud provider, listen to topics, read books… The goal is to constantly sharpen your tools and*skills* and master any topic to a degree that fits your purposes. Be a generalist but specialize in 1-2 topics (I highly recommend Range).
Top comments (0)