What is Security Engineering?
Engineering is about enabling outcomes, but security engineering is about preventing the wrong ones. It’s a discipline rooted in risk management, requiring both technical skill and an adversarial mindset to protect systems from misuse, not just make them function.
A good starting point is really to ask, what is engineering? The etymological root of the word engineer comes from the Latin "ingeniare" or "ingenium". Each respectively means to contrive or devise, and cleverness. It's no wonder the root is shared with the words "ingenious" and "ingenuity". The engineer, thus, is a problem solver. But to say the practice of engineering is to solve problems is somewhat reductive.
The engineer must design, implement, test, adapt and maintain their solutions. They don't get to simply come up with a solution and then walk away; instead, they are committed to the reproducibility and maintenance of their work. The constraints and requirements of each problem vary, and therefore, the degree of all of the above also varies. You would be forgiven for not worrying too much about testing and maintenance if your solution is an MVP designed for the trash heap.
However, generally speaking, the engineer must contribute some energy and resources to each item in that list. This can take the form of documentation, tooling, and other automated systems or environment setups that are never included in the final product, but are still necessary to support it. As a great engineer once told me, "A Chef does not ask permission to clean and sharpen his knives." Yet, the engineer is often required to justify building tools to enable her own work.
The security engineer must perform all of this, but the requirements for the security engineer are skewed towards preventing misuse. To put it another way, any system has an intended use case, an intended pathway for the user (be it human or otherwise), but quite often there is a way to take a different route through an application. This can be simply an error, but it can also be malicious. Commonly, a malicious path is found by chance, and with any luck, it is reported and patched. Security engineering, therefore, focuses on detection, reporting, and patching, as opposed to the product or feature itself.
An engineer working on a security product may not be considered a security engineer unless their work focuses on the aspects described above. Writing anti-virus software or configuring a hardened VLAN requires in-depth security knowledge, and there is a clear overlap in the fields. However, the Security Engineer role is often supplementary to other, more traditional roles, such as Network or Software Engineers. Better yet, the somewhat more modern role of the Site Reliability Engineer has considerable overlap with Security Engineering, as it focuses on the reliability of a system.
The broader point is that a security engineer is not a software engineer who works on a security product, nor is it someone who works in a related field such as encryption, nor is it someone who implements physical controls in a secure system. No, security engineering is not required for a product or service to exist.
That is the key distinction. Engineering typically involves enabling something to happen (e.g., a file can be shared online, the sprinkler system turns on at 11:00 a.m.). Security engineering is about ensuring that something else doesn't happen (e.g., a burglar cannot enter this room, a thief cannot withdraw money from my bank); it is never about the product being sold.
This subsequently always leads to the question asked by finance and product teams all around: why bother with security? After all, it is expensive, it can slow everything down, and it gets in the way of me doing my job. The answer is risk management. Can you take the risk of not implementing security? What happens if the thing you don't want to happen, happens? For many organisations, this is showstopping. Reputational damage is a natural market force that can kill a would-be profitable business; however, there are also legal frameworks that can lead to fines and imprisonment for non-compliance. Furthermore, in B2B contracts, compliance is often required, and a failed audit can result in direct business loss.
And that's just the best-case scenario. Consider the impact of a security breach at a nuclear power plant. Stuxnet could have easily caused damage in a life-threatening way. Or what about ransomware in a hospital? WannaCry led to the re-routing of ambulances away from people in dire need. It is not theoretical to say that security protects people, and failing that, lives are lost.
Risk assessment involves evaluating the likelihood of an event occurring and its potential impact if it does. However, it's also intended to include mitigations that reduce one or both of these factors. As scientists turned on the Large Hadron Collider at CERN in Geneva, people questioned the risks associated with it. They had reported a near-zero chance of creating a black hole and destroying Earth.
However, as many people have pointed out, near zero is not zero. Often, near zero is the best we can do, and there needs to be a pragmatic element to security. What if we had removed the risk entirely by just not turning the LHC on? A question for the philosophers.
To be a security engineer, you must possess a range of technical skills, an adversarial mindset and often knowledge of the law. Designing a secure system, or making a system secure, typically involves user authentication, transaction integrity, message secrecy, and fault tolerance, among other key considerations. A good system will also have a degree of accountability. However, when approaching any task, the engineer needs to consider the specific requirements. Often, when security is implemented, it is done as a checkbox exercise with no consideration given to the actual nature of what needs to be protected and how to protect it.
Thus, many system designers make errors in believing their system is secure because they can list the various things they did to make it so. I can spend a great deal of time ensuring my data is encrypted in transit, but it makes little difference if my end device, where it can be read in plaintext, is left vulnerable.
On that note, there is always a human element to a system. Even if humans are removed from the decision-making process, they still need to be involved in the setup and supervision/maintenance of a system. Proper security relies on the people who support it being adequately trained and motivated.
And so, security engineering is all-encompassing. It's impossible to know it all, and you'll often have to rely on specialists and third parties to fill in the gaps where you are lacking.