Background

Intro

This book is written for the experienced engineer, manager, tester. And not for experienced security experts. Security knowledge has not been very accessible. There are films - and most are horribly wrong. And there are complex books covering a specific topic in depth.

If you not hyper-focused on security is is quite easy to either get lost in myths or complexity.

I want to get you the foundations to contribute to the security of your product.

The takeaway of this chapter will be:

You know who could attack your technology
You know why
You will learn the basic principles of protection
You will also learn about the technology available to the attacker

Principles

There is a list of the most basic principles you can build security on. These principles are very abstract, but are the basics for building more specific tools. This is not a complete list.

Bolt-on-security vs security-by-design

Detecting attacks is a typical bolt-on way of security. Anti-Virus, Network intrusion detection, behaviour detection, … These kind of things are bolt-on-security. The other big security philosophy is security-by-design.

If you are responsible for building a system use security-by-design. In many cases you are not free to do it the perfect way - for example a manager needs an old Internet Explorer to use am esoteric web based application installed on his PC. In this case bolt-on-security (filtering files and URLs) is a valid approach.

Disadvantages of Bolt-on-security is: It adds complexity (file parsing, for example).

This can turn the bolt-on-security into a new infection vector.

To protect against it, isolate it from other systems (segmentation): Sandboxing and an own machine for the file processing are options.

Two tactics with bolt-on-security:

Add it to the outer perimeter of your network to reduce the normal “internet noise” of attacks. This will reduce your important monitor-log reports.
Add it to the innermost perimeter to detect attacks that bypassed your protection.

A whole part of this book covers bolt-on security. If your are stuck with a given design bolt-on will be a good way to go.

The next principles are part of the security-by-design philosophy

Threat modelling

Threat modelling is a process organized by the designer of the software but including a multi-skill team of people involved in the project. Goal is to identify potential threats to the developed tool as early as possible and to find fixes and mitigations.

It is not complex but can turn out to produce lots of documentation.

There are four basic steps that need to be done to model threats:

Create overview
Brainstorm potential attacks
Rate severity
Define fixes and create priority to implement them

For those steps there are many tools (methodologies/checklists) to guide your team through.

Which one to pick will depend on mood, team, and especially your project.

An improvised one would be:

Who will attack your technology ?
What is the goal of this person (data, money, …)
Which resources can this person gather ?

There will be a specific chapter on threat modelling

Reduce Attack Surface

Attack surface is everything that can be reached from the outside. These are servers, interfaces, network connections. You can reduce this surface by asking yourself some simple questions:

Which features do you really need ?
- Remove unnecessary programs and features
How to put steel plates on the technologies I have to keep ?
- Reduce features, reduce privileges, ….
How to reduce the potential impact ?
Who do you (have to) trust ?
- Best case: You do not have to trust anyone

Compartmentalisation / Segmentation

Segment your system into small partitions. Define narrow communication channels. Maybe they can be one-way (data-diodes). Possible segments can be:

Multiple isolated VMs on a machine
Multiple isolated processes on an OS
Multiple isolated network segments
Sandbox the processes
Isolated servers
Split a big application into smaller compartments
- Example: Browsers have separate processes for tabs, extensions, …

Dropping privileges is a part of that.

Principle of “Least privilege”

Reducing available privileges reduces the impact of a hacked process or account. This reduction can be done on account level (special web server accounts, for example) or on process level (where the process drops privileges during startup - as soon as it does not require them anymore).

Dropping process privileges is possible on Linux. Not on Windows.

At least you can terminate the program if is run by root (as long as it is a potentially vulnerable program).

Landlock

Newer Linux kernels are shipped with the landlock module. Ths allows code to manage the own privileges. Your program should drop all privileges it does not need at startup.Many programming languages do support that:

C: https://en.ittrip.xyz/c-language/c-sandbox-security
Rust: https://docs.rs/landlock/latest/landlock/
Golang: https://github.com/landlock-lsm/go-landlock
Python: https://github.com/Edward-Knight/landlock

For command line execution use the cmdline tool “landrun”

Updates

After a vendor created a patch it takes the bad guys a few hours to reverse engineer the patch and find the vulnerability which has just been patched. Within days there are attacks. Update everything ASAP. Especially if it is network connected.

Flexibility

Whatever you do: Be flexible. You did threat modelling during the design phase, you fixed all vulnerabilities you found. But there will be a hack.

Expect the attacker to find a trick against your tools in the following weeks. Have a plan ready to handle that situation. Expect the attacker to do something unexpected. Plan for flexibility.

Do not make mistakes

“Bitte immer alles richtig machen” in German. This is the core principle especially in Design and Coding. It kind of sounds obvious and boring. But there are ways to engineer fault-reduction with tools and processes.

Those are for example:

Secure coding
Compiler mitigation
Testing
Fuzzing

De-centralisation

De-centralise everything. Centralised components (servers) can be DDOS-ed. Will your IoT device still work when the server is down ? Which functionality is available in offline mode ? Could you add fallback servers to the plan ? Could the user override the server for a short time ?

Fail gracefully

Do you want your system to fail-close or fail-open ? What does the car’s door lock do when there is a power outage ? Lock or Open ? Plan these failures and the consequences. How can these failures be triggered and by whom ?

Monitor / Incident Response

Expect a hack to happen. But many hacked companies do not notice the breach - or do, hundreds of days later and by accident (server misbehaves or similar).

You do not want to be one of those. You could monitor the devices you own or the devices you sold to customers (IoT, for example) for security incidents. For “monitoring sold devices” scenario: respect privacy !

There is SIEM (Security Information and Event Management) software for that. Connect your technology to a SIEM.

This enables you to respond (“incident response”) when something happens. This has several benefits:

You can respond (updates, isolate infected devices, ….)
Learn from this incident for the next projects

Educate users

Users want the option to know what their technology is doing. Having two layers (simple and detailed) of information will very likely be embraced ¹.

Your security plan should not depend on users reading, understanding and acting upon this information. But having smart users will add new “sensors” for unexpected attacks to your environment. Especially attacks containing social engineering. Those users would need a fast channel to contact the person in charge for reports on attacks.

Defense in Depth

As protection mechanism will fail - the attackers will find holes - it is better to layer defenses. To protect an asset it is essential to layer different kinds of defenses to make attacking more complicated to request different skills.

As for a castle example:

A castle on a hill has a moat, walls and archers.

Attackers will have to be:

Good runners
Swimmers
Climbers
Lucky

To reach their goal alive.

This will narrow down the number of successful survivors/attackers quite well.

The same is true for your computer system. Combine different technologies to protect an asset. Even if you think the one specific layer you just designed offers 100 % protection.

Filter at the endpoint

Thanks to efforts by the EFF, Google and many more the connections between client and server are now end-to-end encrypted (HTTPS). Which is an incredible security improvement. Many bolt-on security solutions offer a feature to scan the content of those connections with MITM proxies. This is only possible if you sabotage the alert system at the endpoints. Because they detect the attack a MITM is. Systems having a sabotaged alert have trouble detecting malicious attacks. Scanning as MITM is a very bad idea.

The solution is: Filter at the endpoints. In the browser, When files are written to the endpoint system, …

The user (or the admin - for larger installations) should also have full control about what is filtered.

Tripwires

Add tripwires to your design. One example is to fill your database with some fake customers with made up mail addresses. As soon as those mail addresses start receiving mails (SPAM), you know the db has been compromised.

The same for fake “password.txt” files in your system. They get accessed ? You got hacked.

Tripwires are useless if you do not have a monitoring system and a plan how to react.

Slow down the attacker

Bank safes have a timed lock. Only after a certain time they open. Thieves will be slowed down. With an alarm system and a police unit to respond this is powerful. Without those to additional ingredients it is useless. Maybe you can build something similar into your systems. Slow down, alerts and response.

Security by Obscurity

A bad idea. There are disassembler tools that help to reverse engineer executables. If any security depends on secrecy it will break as soon as an experienced person attacks it. You are an experienced engineer but not an experienced attacker. The guys you face have the skill set switched: experienced attacker, OK-ish engineer. This is why they became attackers.

Long story short: if your defense depends on “as long as the attacker does not know X” it already failed.

And just in case you think these disassembler tools are out of some fairy tales:

IDA, paid and free test version. For Mac/Win/Linux
Hopper, Mac/Linux. Test version available
Radare2, Mac/Windows/Linux/…

Security Theater

A big show towards the customer faking security features. Most often has an intended negative effect on usability - you want it to be noticed. It is also not necessarily cheap.

One typical example is the water bottle ban at airports.

Please double check if what you are implementing is just smoke and mirrors or some proper solution. And go for the proper solution.

Hollywood threats

Also on the negative side: Thanks to Hollywood movies everyone seems to know how an attack looks like - with lots of show effects and world shattering scale. When discussing security with security-beginners there will be a tendency for the discussion towards those Hollywood threats. Explain to everyone this concept. Have some real-world hacker stories ready and try to steer the discussion towards a productive region. Even if it is less exciting.