Preface

This book

Goals

Your next project will be more secure than your last project. And this will be almost hassle-free. This is the mission of this book.

This is why I wrote it.

As an experienced engineer, software developer and security guy I want to help you getting started with security features in your projects.

My observation is that there are many specific books for security topics. But almost no “getting started” books.

This is the itch this book wants to scratch.

Release early, release often

One of the reasons I dare to write a book is leanpub’s feature to release early and often. That way I can see progress and get feedback.

Please visit the forum and help me improve the book. Or contact me:

• On Twitter: @ThorstenSick
• On Mastodon: @thorsi@chaos.social

As I have been spending lots of time with security focused engineers, the most important things I want to learn first from you:

• What causes trouble ?
• What kind of technology is currently introduced in normal engineering ?
  • Where does it cause issues ?
• What kind of normal technology (cloud, micro services, IoT) are you using ?

Boiling down to: What do you need from this book ?

80/20 or Pareto Principle

Following the Pareto principle I will focus on finding the important 80 percent of security tips first and later filling in the missing 20 percent.

This will result in:

• I start a new topic before I squished the last drop out of an older topic
• Instead of spending hours to fine tune the language and optics of an existing chapter I start a new chapter with dozens of new tips

This does not mean I will not do that sooner or later. But I want to get the low hanging fruit first. I also feel like you expect a book containing lots of good tricks instead of poetry.

Form follows function

With every iteration of the book I will tune the optics, improve the layout and maybe add images.

But adding new chapters is more important.

All this said…

Adding security features to a project can be fun and quite rewarding. Cherry-pick ideas from this book and get started.

Structure of this book

This book is meant to be read twice. First by cherry picking interesting topics and a second time as toolbox when implementing a feature.

For this reason the book is split. The first few chapters offer an introduction to the security landscape. The second part contains chapters helping to solve specific problems.

Do not feel bad if you directly skip to something interesting. Or to a chapter that is currently relevant for your project.

Project phases and audience

A project has different phases. Depending on your institution different people could be responsible for each phase. Everyone can contribute to security. And security will break at the weakest link.

Stages in development are:

• Management
• Architecture/Design/Project Management
• Development
• Testing
• Support
• Analysis (analysis of attacks)

Content

Background

Know your enemies

Describes the types of adversaries your project can face. And their high-level goals, resources, technologies and tactics. You should know your enemies

Attacker’s goals

An in depth list of goals and sub-goals the attackers have - things you will want to prevent happening. Block the attack, protect your system.

Principles

High level principles you can use to design a secure system. These principles are abstract - and you will be able to combine several of them in designing your project.

Planning

Threat modelling

A mixed group of people (engineers, architects, managers) meets for a threat modelling session. Understanding the strengths and weaknesses of the product and the planned new features. “What would an attacker want ?”, “How would he get that ?”. Identifying that is the first step to protect the valuable assets. It can sound intimidating. But there are so many different approaches to make it simple and even fun. I collected a range of “best of” approaches in this chapter.

Software Design

Software design - also known as architecture - is the bigger picture of the technological part of the project. A good design can speed up development, simplify testing, and increase security. This chapter covers the security basics of software design. Followed by specific topics in other chapters.

Vulnerabilities

Your software - and maybe even your hardware will have bugs that turn into vulnerabilities. Ready to be exploited by an attacker. The chapter Vulnerabilities will cover the essence and taxonomy of vulnerabilities. Understanding that will make decisions based on vulnerabilities simpler.

Security process

Internal set up of a project will decide if a external vulnerability report is a disaster for the project release cycle or can be handled in a relaxed and simple way. Being prepared for the inevitable is central in this chapter.

Software Design Checklist

The Software Design Checklist introduces you to a source to learn about typical software design flaws. It also starts to create an (incomplete) list of typical flaws encountered it real world failed projects.

UX

How to create a user interface in a secure way - preventing the user from becoming the weakest link.

Updates

As soon as a software reaches a certain complexity you need updates to ship patches. This chapter guides you through the challenge of shipping updates in a secure way.

Passwords

Passwords are the main way the user authenticates himself. Handling that in a secure fashion can turn out to be quite complex - but at the same time there is enough experience around.

Browser

The browser is the main software running on most computers. And the interface for a lot of other technologies. As browsers are complex they are vulnerable. Some things can be done to improve browser security - or the security of connected web admin platforms (router config page).

Censorship

This chapter should be named Resilience. But Censorship attracts more attention. Our computer systems are very complex. And many do not have enough redundancy to recover from a single failure (accidental or intentional). But they can be built that way. This is covered in this chapter. It currently focuses on personal redundancy. Later it will be extended to also cover how to build resilient systems.

IoT

Things are getting more smart. Embedded Micro-controllers are cheap. Security is very often not existing. This chapter helps to improve that.

CAN

The CAN bus connects micro-controllers in many embedded systems - especially in vehicles. Securing it is a challenge - as it was not designed for security. This chapter will give you some tools - and basics for fuzzing CAN.

Bluetooth LE

Low Energy Bluetooth can be integrated in many systems. Security is hard to implement. But possible. This chapter will give you the tools and basics to improve security.

TLS

TLS is a basic technology to secure data in transit. Some may know it as SSL or HTTPS. And many projects use it.

Crypto algorithms

Which algorithm to use ? In which mode ? Best key length ? This book is basic, so this chapter will be more of a cheat sheet for those essential things. For the curious people: there are resources to dig much deeper.

Programming

Code analysis tools table

There are several tools that will assist you during the coding process. This table will help you to pick the proper ones.

Defensive programming

Some coding techniques will harden your code against attackers. Positive side effects like making your code simpler to debug and more robust and stable are take always that balance the extra effort invested. If you do not yet practice defensive programming you should consider starting it.

Assert

A very powerful tool for debugging and preventing bugs are asserts. They are even more powerful when combined with fuzzing. When coding, you should start using asserts right now.

Compiling

Modern compilers have lots of less known features to find vulnerabilities during compile or run time. Or even mitigate - making vulnerabilities harder to abuse by the attacker. Covered in this chapter.

Clang LLVM

Clang is a compiler in the GCC league. It adds some more features for static and dynamic testing of your code. Those features are cool enough that you should consider compiling at least the test version using Clang and those settings.

JavaScript security

I am a big fan of automated security tests. And JavaScript has its own pitfalls. But those can be fixed by tools you can integrate seamlessly into your workflow. The JavaScript security will show you the low hanging fruit.

Testing

Testing compiled binaries

To verify that the compiler properly hardened your executable the way you wanted you (or your testers) will want to use some tools. This is described here.

Flawfinder

In addition to your compiler the tool Flawfinder gets you more verification of your code. With zero effort.

CPPCheck

CPPCheck is Flawfinder enhanced. With the small drawback that you will have to invest some time in configuration. This chapter will help you there.

Testing

Is it still testing or already hacking our own product ? There are many tricks to make software testing more aggressive and which will shine some light on vulnerabilities in this chapter.

Fuzzing

Fuzzing is a technology to find unexpected bugs - most of them potential vulnerabilities. Pre-existing tools and DIY scripts can do the fuzzing for you. How to get started is described here.

Tools

Several tools are essential to build secure software. This covers version control systems, SSH and many others that “just” support you in getting your tasks done. Those are covered in this part of the book.

SSH

A very powerful tool that goes way beyond just replacing Telnet. Know it and simplify your work while being more secure. Or - if you build embedded systems - integrate it in there.

Git

Git as a version control system is the core of your development workflow. It is also a perfect spot to add automated code quality tools. You learned about those tools in the other chapters. And this chapter gives you some hints where to get started integrating them into Git.

Bolt-on security

Bolt-on security is what is done of someone missed to do security-by-design. Especially myths make it hard to find the right way to use it. These chapters will bust some myths.

Antivirus tests

How to properly read antivirus tests. As antivirus is neither a silver bullet nor useless a proper estimation of its power should be done first.

Antivirus integration

Antivirus can only scan files it gets access to. Many projects could benefit from an interface between the project and an already installed antivirus. And Microsoft is offering one.

Antivirus sharing samples

There are several reasons to contact an antivirus vendor

• They have a False Positive on your software
• You found undetected malware (files or URLs)

This chapter will help you getting started and give you some internals - the people working in an antivirus lab are on your side and will love to cooperate.

Antivirus: VirusTotal

VirusTotal is the go-to way of quick scanning potential malware and false positives. But has an own tricky personality. Knowing that will prevent you from coming to the wrong conclusions.

Antivirus: Behaviour based classification

Unknown samples must be classified before detection can be created. A quite reliable way to achieve that is behaviour based classification. Especially it is quite simple to interpret the resulting log for malicious behaviour. The basics are covered in this chapter

IOC sources

IOC sources is a collection of lists of so called Indicator Of Compromise Sources. Those are Malware executables, hashes, URLs, registry key, …

The lists can be used for training, learning or (if they are curated) event directly blocklisting.

Offense

Even if you are playing Defense - it is very important to know the tools, tricks and tactics of Offense. The basics are covered here.

Kill chain

A kill chain is a typical structure of an attack. With different steps happening in between “the attacker decided to attack” and “the attack succeeded and is spending the stolen money”. A kill chain can be interrupted at any stage. Knowing kill chains will help the defender.

Recon NG

An early part of manual attacks is reconnaissance of the target. There are several tools helping the attacker doing that. The same tools help defenders estimate their attack surface. One of those is Recon-NG.

Google Dorks

Google Dorks are simple reconnaissance tricks abusing Google. Using them it is possible to learn about vulnerabilities in web pages without event connecting to them once.

BeEF

BeEF - Browser exploitation Framework helps you exploiting browsers. And those are very often the most central application in a person’s life.

Burp Suite

Burp suite is attacking the other way: Connecting to a web page and while crawling it enumerating the vulnerabilities.

Mitmproxy

Mitmproxy is a python proxy to intercept especially HTTP communication. Valuable for development of network communication, testing and pen testing.

Appendix

The appendix contains handy things that will make the reading of the book more enjoyable. Especially:

External References

A list of external references (books, talks and homepages).

Glossary

There are so many new acronyms in the security field. And even there they are territorial - Web security being totally different from Assembler hacking. Have a glossary ready. Here it is.

The author

Who wrote this book and: Why ?

Authors

As the security field is so large I want to have other authors contribute to their field of expertise. This chapter is ready to introduce them. Even if I just slowly started to invite people.

Changelog

Read this first after you got an updated book

License

If you want to do anything else with this book besides reading it - this chapter is for you.