My Core Principles in Security Engineering
  1. “Is this secure?” – Secure against what?
    • i.e. A successful attack is just a function of Time x Resources
  2. Focus on trust boundaries & data flow
  3. Total Return on Investment (ROI) is paramount
  4. People > Process > Technology
  5. Knowing when NOT to build is more important than building
  6. Always, always, always map risk to controls
  7. Develop a threat model BEFORE building shit. It will save you time & money. There is zero excuse.

As a Security Engineer / Architect, we frequently have to decide between developing custom tooling vs buying vendor solutions (sometimes a mix). Engineers love to build things. They (usually incorrectly) believe they can build it better. Do not underestimate the benefits of a good vendor solution. You are accepting a ton of risk for your organization while you read up on techniques and open-source solutions to help you satisfy controls. Good vendors have sunk lots of time, money and expertise to give you a solution that can get you 80% of the way there. Sometimes the last 20% isn’t necessary or it could be too expensive to obtain (time, money, expertise, etc.). On the flip side, do not treat vendor solutions (even big names) as a black box. Understand how it works and go from there.

On the flip side, building custom solutions can be extremely helpful. You can usually customize the solution to fit your exact needs (if you know what that is). It usually makes your team much more knowledgeable in the area. Lastly, you can push out updates as fast as you want!

As always, the right choice is not straight forward. There are some security domains that you shouldn’t bother going the open-source route. For example Anti-Virus and EDR is a very mature market. You will not make a better solution. However when you are looking at a log management system, maybe you grab Elasticsearch and manage your own clusters. Most of the time a mix of vendor and custom tools allow you to get the best of both worlds.