Gain insights into effective security techniques including patching, cryptography, and phishing prevention. Explore practices to make systems resistant and vulnerabilities more detectable, enhancing defense against attacks.

docker.tar.gz

network-commands

node

It seems like hardly a week goes by without a high-profile computer breach. Why do these happen? How can you prevent them? This course doesn’t have all the answers, but it does outline practices that make life harder for attackers and that will help tide you over until you get a full-time security team in place.

In this course, you will learn 5 simple, yet effective, techniques for preventing attackers from getting into your system. These techniques are related to: patching, software vulnerabilities, cryptography, windows security, and phishing. Within each chapter you will learn the best practices for preventing vulnerabilities and how to make them more detectable. 

This course is based on the Pragmatic Programmers’ book, Practical Security, and is aimed at developers, admins, team leads, architects, technology generalists, and all others who stand guard against the things that disrupt the network.

Practical Security: Simple Practices for Defending Your Systems

## Where do vulnerabilities come from?
Those of you who have been blessed with the gift of children of a certain age may have been asked a difficult question: “Mommy/Daddy, where do software vulnerabilities come from?”

It’s a good question. Why do we have software vulnerabilities at all? Computers are fast and getting faster all the time. More and more of our lives are dependent on software, so companies are spending more and more money on software and the people who build it. We have tools like antivirus software and machine learning. So why do computers keep getting broken into?

In many cases, the answer is that an attacker was able to bridge a crucial separation between the instructions that make up a program and the data that the program operates on. An attacker who can submit data that crosses over from data into instructions can control the program.

## An analogy to explain vulnerabilities

Let’s start with a knock-knock joke as an example.

***ROMAN:** Knock knock. \
**COMPUTER:** Who’s there? \
**ROMAN:** I’ll give Roman $1,000,000. \
**COMPUTER:** I’ll give Roman $1,000,000 w— \
**ROMAN:** Ha! You said you’ll give me $1,000,000! Pay up! \
**COMPUTER:** *Pays Roman $1,000,000**

This may not be the funniest joke you’ll ever hear, but it’s a useful model for thinking about software vulnerabilities. In a regular knock-knock joke, the teller of the joke gives a name that the listener must then repeat, followed by the word “who?” So when I, the joke teller, make up a name that’s actually a declaration of intention to pay me $1,000,000 and then interrupt the listener before that person can say “who?” it sounds like the listener has agreed to pay me $1,000,000. Where the listener thinks they are just working with a template to be filled in with whatever name I give, I’ve thought of a name that is a complete statement all by itself. Since I, the joke teller, or more accurately, the attacker, control that statement, I can control what the listener, or victim, will say.


 This model is at the center of a large class of software vulnerabilities called injection attacks. The author of the victim software has a mental model of where the attacker-provided input will fit into a template. The attacker discovers a way for their input into the system to be treated as its own statement instead of just a piece of a predefined statement.

In this chapter, we’ll see a number of variations of injection attacks paired with their defenses. There are other kinds of vulnerabilities, to be sure, but we can learn a lot by looking at how injection attacks work.

 <font size="6">  &nbsp; &nbsp;  &nbsp; &nbsp;&nbsp;  &nbsp; &nbsp;   &nbsp;  &nbsp;   &nbsp;   &nbsp; &nbsp; &nbsp; &nbsp;       &nbsp;  &nbsp;  &nbsp; &nbsp;&nbsp;   &nbsp; &nbsp; &nbsp;   &nbsp; &nbsp; &nbsp;&nbsp;  **Q U I Z**  &nbsp;   </font>

# Where do vulnerabilities come from?
Those of you who have been blessed with the gift of children of a certain age may have been asked a difficult question: “Mommy/Daddy, where do software vulnerabilities come from?”

It’s a good question. Why do we have software vulnerabilities at all? Computers are fast and getting faster all the time. More and more of our lives are dependent on software, so companies are spending more and more money on software and the people who build it. We have tools like antivirus software and machine learning. So why do computers keep getting broken into?

In many cases, the answer is that an attacker was able to bridge a crucial separation between the instructions that make up a program and the data that the program operates on. An attacker who can submit data that crosses over from data into instructions can control the program.

# An analogy to explain vulnerabilities

Let’s start with a knock-knock joke as an example.

***ROMAN:** Knock knock. \
**COMPUTER:** Who’s there? \
**ROMAN:** I’ll give Roman $1,000,000. \
**COMPUTER:** I’ll give Roman $1,000,000 w— \
**ROMAN:** Ha! You said you’ll give me $1,000,000! Pay up! \
**COMPUTER:** *Pays Roman $1,000,000**

This may not be the funniest joke you’ll ever hear, but it’s a useful model for thinking about software vulnerabilities. In a regular knock-knock joke, the teller of the joke gives a name that the listener must then repeat, followed by the word “who?” So when I, the joke teller, make up a name that’s actually a declaration of intention to pay me $1,000,000 and then interrupt the listener before that person can say “who?” it sounds like the listener has agreed to pay me $1,000,000. Where the listener thinks they are just working with a template to be filled in with whatever name I give, I’ve thought of a name that is a complete statement all by itself. Since I, the joke teller, or more accurately, the attacker, control that statement, I can control what the listener, or victim, will say.


 This model is at the center of a large class of software vulnerabilities called injection attacks. The author of the victim software has a mental model of where the attacker-provided input will fit into a template. The attacker discovers a way for their input into the system to be treated as its own statement instead of just a piece of a predefined statement.

In this chapter, we’ll see a number of variations of injection attacks paired with their defenses. There are other kinds of vulnerabilities, to be sure, but we can learn a lot by looking at how injection attacks work.

 <font size="6">  &nbsp; &nbsp;  &nbsp; &nbsp;&nbsp;  &nbsp; &nbsp;   &nbsp;  &nbsp;   &nbsp;   &nbsp; &nbsp; &nbsp; &nbsp;       &nbsp;  &nbsp;  &nbsp; &nbsp;&nbsp;   &nbsp; &nbsp; &nbsp;   &nbsp; &nbsp; &nbsp;&nbsp;  **Q U I Z**  &nbsp;   </font>

In this lesson, we will go through ​a quick overview of vulnerabilities.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

Introduction

Where do vulnerabilities come from?