Why engineers need to care
Security used to be something that happened on office computers. Now sensors, controllers, vehicles, medical equipment and building systems often connect to networks, and a weakness in any of them can have physical consequences as well as data ones. That makes basic security literacy part of an engineer’s toolkit, whatever the discipline.
This article covers fundamentals only. It is general information, not professional security advice. Requirements differ by country and industry, and regulated sectors have their own standards and specialists. Follow the ones that apply to your work.
Start with what you are protecting
Security work usually begins with three questions: what do we have that matters, who might want to misuse it, and what would happen if they did? The answers shape everything else.
Three properties are commonly used to describe what is at stake:
- Confidentiality: only the right people can read the information.
- Integrity: the information or system has not been altered improperly.
- Availability: the system works when it is needed.
Which of these matters most depends on the system. For a thermostat, availability and integrity may matter more than secrecy. For a patient record, confidentiality weighs heavily.
Common kinds of threat
The list below is general, not exhaustive.
- Phishing and social engineering. Tricking a person into revealing credentials or running something harmful. People are often an easier target than software.
- Weak or reused passwords. Credentials that are guessable or shared between services.
- Unpatched software. Known flaws that have fixes available but have not been applied.
- Malware. Software that acts against the owner’s interests, including ransomware that locks data.
- Misconfiguration. Default passwords, open ports, or overly permissive settings left in place.
- Insider mistakes and misuse. Accidental or deliberate harm from people with legitimate access.
- Supply chain issues. Weaknesses in third-party components, libraries or services that you rely on.
Most incidents involve ordinary weaknesses rather than exotic attacks, which is encouraging because ordinary weaknesses can be reduced with ordinary discipline.
Principles that apply almost everywhere
Least privilege
Give each person, program and device only the access it needs to do its job, and no more. If an account is compromised, the damage is limited to what that account could do. Review access when roles change.
Defence in depth
Do not rely on a single protection. Layers such as network separation, authentication, monitoring and backups mean that one failure does not mean total failure.
Keep things updated
Many successful attacks use flaws for which fixes already exist. Patching is not glamorous, but a process for tracking and applying updates is one of the most valuable habits. In embedded or industrial equipment, updates may be difficult or risky, so plan for how a device will be maintained before it is shipped, not afterwards.
Secure defaults
Ship products with no shared default password, with unnecessary services turned off, and with the safest reasonable settings enabled. Users often never change defaults.
Strong authentication
Unique passwords, a password manager and a second factor where available reduce the chance of simple account takeover. Keep secrets such as keys and tokens out of source code and out of version control history, where they are surprisingly easy to leak.
Encryption in the right places
Encrypting data in transit and at rest protects against many kinds of exposure. Use well-established, widely reviewed libraries and methods. Writing your own cryptography is a well-known way to introduce flaws.
Backups and recovery
Assume something will eventually go wrong. Backups that are kept separate and tested for restoration turn a disaster into an inconvenience. A backup you have never restored is only a hope.
Building security into design
Adding security at the end is costly and usually incomplete. It works better when treated as part of the engineering design process from the start.
- Write security requirements. Include them in your requirements engineering, alongside performance and reliability. Many belong among the non-functional requirements.
- Think like an attacker. A lightweight exercise, listing what could go wrong at each interface and who might cause it, is a common approach called threat modelling. It resembles hazard identification in safety work.
- Minimise what you collect and keep. Data you do not hold cannot be stolen.
- Validate inputs. Treat data from outside your system as untrusted until checked.
- Test for it. Include security-relevant cases in your software testing, and have someone else perform code review with security in mind.
- Plan for the whole lifecycle. Consider how a product will be updated, supported and eventually retired.
Habits for individuals
- Be sceptical of unexpected messages, particularly ones that create urgency.
- Lock your devices and keep software current.
- Use separate accounts for work and personal tasks.
- Do not share credentials, even with colleagues; ask for access instead.
- Report suspicious events early. A culture where reporting is welcomed works much like near-miss reporting in safety: small signals prevent larger incidents.
When something goes wrong
Have a plan before you need it: who to contact, how to isolate affected systems, and how to preserve evidence. Afterwards, review what happened in a blameless way, focusing on how the system allowed the failure. That approach mirrors blameless reviews in other engineering areas and tends to produce more honest accounts.
Rules differ by sector
Healthcare, finance, energy, transport, defence and consumer products each face different legal and standards requirements, and these change over time and between countries. This article cannot tell you what applies to you. Your organisation’s security staff, legal advisers and the relevant standards bodies are the right sources.
Security is never finished or perfect. The practical goal is to make attacks harder, limit the damage when they happen, and recover quickly, which is a goal engineers are well placed to work towards.