Introduction

This blog gives an introduction to the Security Engineer career profile by stating some general facts about Security Engineers. If you work closely with a security engineer everyday, perhaps you’ll find some funny facts in this blog post that you can relate to and may help you understand how we think. Additionally, if you’re interested in becoming a security engineer, I hope this blog post can inspire you to follow that path. In any case, I hope you have fun reading it!

Thirteen facts about Security Engineers

A security engineer doesn’t know everything, in fact, no one knows. What would be the fun of that?

Somehow most development teams I work with have this idea that a security engineer is an expert in all of the software development areas: front-end and back-end development frameworks, software architecture patterns, software development methodologies, network virtualisation, cloud services, application security, hardware security, cryptography, public key infrastructure, you name it. I wish that was true, but it isn’t. We certainly have some expertise in specific areas, but for the other ones we just have a high-level knowledge. Nevertheless, in general, we’re aware of our weaknesses and knowledge gaps, and whenever we don’t know something important I can assure you that we’ll be really committed to learn it. So don’t get frustrated when you hear I don’t know, followed by I’ll try to find out. This is ok and should be appreciated.
A security engineer abstracts a lot, but then breaks everything into very very small pieces. Details matter a lot.

Software systems are very complex. Reasoning about security as whole without a high-level overview of the service you’re building it’s hard and error prone. So we start high-level and we peel the layers, one by one, until we get to very low level details. Then we go back and repeat this process 1000 or more times. This is can be an exhausting mental fitness exercise for everybody involved in the process. But this process tends to deliver the best security results. So be patient!
A security engineer doesn’t know all business areas in detail, nor wants to, it would be overwhelming.

Some business areas are easier to understand and reason about than others, but that doesn’t mean that we cannot try to understand the essence of all of them. What’s important is that we learn the essence of a particular problem. From that moment on we can quickly reason about its security. So don’t shy away. You should always explain the problem at hands to your security engineer, even if you think it’s a complex one. I bet you’ll be surprised with the outcome.
A security engineer gives advice, in fact, very good advice.

We help development teams build secure systems by bringing our knowledge and experience. We see so many systems and so many issues, that inevitably we build up better mitigation mechanisms and much more resilient ways of addressing those issues. But we don’t stop there. We challenge you to take distinct perspectives, and sometimes, to consider the impossible. So when we tell you to go in a certain direction, be critical (we’re not always right, of course) but listen to our advice and take it seriously. We know that building a trust relationship takes time, but sometimes we don’t have much time to loose.
A security engineer considers the unthinkable, the impossible.

Yeah, I know this happens a lot. It’s in our line of work to think the unthinkable. This happens because we dive so deep into the problem that we start hypothesising something that is almost impossible. Sometimes this adds little value to the discussion and borderlines paranoia. Yes, we are aware, but the truth is that we’re obsessed with securing everything. So don’t worry, it’s normal. I can assure you that with time and experience we tend to be more practical. But remember, for us, nothing is really impossible. It might be less likely, but there are no impossibles in the field we work at.
A security engineer doesn’t like complex systems. Complex systems are insecure.

We all like engineering challenges, incorporate the latest technology, the latest methodology or architecture. It’s cool to build these giant service with thousands of micro-services containing amazingly complex flows using the latest trendy technology. This might seem nice at first, but we tend to forget the long term impact of our decisions. Building complexity into software systems always introduces high risks when it comes to security. There’re gazillions of failed, insecure projects that can attest this fact. I actually dare to say: the worst enemy of security is complexity. So when security requirements implementation leads to introduction of complexity in the system, stop and re-think the design. Most likely, the complexity introduced doesn’t compensate for the risk it mitigates.

Remember: you can’t secure what you can’t understand. So keep it stupid simple (KISS)! Next time you start building a software system ask yourself, do I really need to introduce that complexity to achieve the desired outcome?
A security engineer is a mentor and coach.

We help you build secure systems. This can be a long process, but once you learn how to reason about it, you should be able to take decisions on your own. We’ll be there to support you nonetheless, but we consider our mission accomplished when you become a security engineer yourself.
A security engineer is able to master all the programming languages in the world. Don’t worry if you invented a new one. We be able to help you, regardless.

This is one of the most funny things we face everyday. Yes, we’re not programming language specialists, but with time, after gazillions of lines of code reviewed, we’re able to master any programming language and conceive our own opinion about how you should do it better. It’s a fact!
A security engineer likes to break systems, a lot.

You can’t learn how to fix something you don’t know how to break. So yes, we break stuff, a lot! It’s a mean to an end. After that we learn how to build, most importantly, how to build it in a secure way. Don’t be mad next time we break your (hopefully test) environment during a penetration test.
A security engineer will question everything. It’s just in our nature!

This is one of the parts of this profession that I find the hardest, specially, when we’re meeting the development team for the first time. Questioning everything generates some sort of discomfort. We know, but let me explain. Security engineers are, in general, very forthright, they barely have time to loose. So when evaluating a new system, they go straight to the point and they immediately question the security (or lack of thereof) of your system. Questioning decisions, features, implementations is natural. We just expect you’re able to explain (in detail, yes, you need to own it!) what you’ve built and why you have built in that way. Understanding the why helps us to fine tune the type of security controls we can implement. Not all the systems are the same and only with the deep understanding of the problem at hands we can come up with the most effective security controls that are better suited for your use case.
A security engineer can change opinions in the event of new evidences or knowledge, it’s ok, in fact, it’s appreciated. We call it growth!

There are no absolute truths in the security world. What was secure today, might be broken tomorrow.

Everything is secure, until someone proves it’s not.

This is the main security axiom. Yes, security is yet another math problem. In fact, defining the security level of a certain system is a probability function. Juggling with probabilities is what we do. So it’s natural that when we learn something new related to a certain problem and the probabilities change, we also change our opinion. This doesn’t mean we’re not consistent in what we do, nor that we change our opinion all the time. However, if this happens it’s because, for instance, we learned how a new attack can affect your system. This is also the reason why you should evaluate the security of your system regularly and often.
A security engineer multitasks a lot, prioritises a lot and masters these skills very well.

The world isn’t perfect, so isn’t the security of our systems. On top of that, software systems are complex, in fact, very complex. So we compromise, a lot! The formula for systems with low amount of security vulnerabilities, relies on finding the right balance between introducing more complexity or accepting a good compromise. Finding this balance in what a good compromise is, requires prioritisation. Defining what’s the most critical risk and which ones should be addressed first, is part of the job.
A security engineer might say a bunch of stuff you don’t understand.

Have you ever been in a situation where you’re explaining the problem and some engineer in the room starts talking non-stop about a bunch of things (about your system) that you don’t understand? How did that feel? It goes from a mix of: Wow(s)! to Who’s this idiot? Doesn’t it? Well, we all have been there and in a way or another, but the fact is that sometimes this person is the security engineer. The reason is simple, we (security engineers) can get too caught up in the details and vigorously express our thoughts without realising that the audience is not falling us. But the solution is quite simple, just call us out! and gives us some slack. We’ll certainly slow down and try to explain the problem we see in a way you understand. We know that if you don’t understand the security risk you’ll never be keen to implement the mitigation.

Conclusion

I guess that like any another engineer, a security engineer sees a lot, learns a lot and forgets a lot. The difference is that we’re passionate about and obsessed with security (whether it’s software security or hardware security). Be assured that every day we try to make your system a little bit more secure. This is a challenging, rewarding and gratifying career path. So, don’t be afraid to become a security engineer, it’s actually a lot of fun!

Additional remarks

As usual this blog post reveals my perspective and experience through out the years. It tries to give the perspective of a security engineer, but that doesn’t mean all security engineers think or behave in the same way.