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

## Bugs in the crypto can have a huge impact
Writing cryptography software isn’t like writing regular software. When writing regular software, little bugs tend to have little impacts. If you have an off-by-one bug, you could expect a small bug, for example, omitting one result on a search page. If you forget to check for null references, maybe a program crashes. But with cryptography, a small mistake may leave you with a system that encrypts and decrypts correctly for well-intentioned inputs but fails entirely when faced with malicious input. 

The developer needs to either rediscover the entire field from scratch or subject the code to the scrutiny of others with a deep understanding of the field. Just as you can’t tickle yourself, you can’t find the mistakes you’ve made that involve flaws you haven’t learned about yet. Bruce Schneier has a nice essay on [Schneier’s Law](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html) that expands on this.
## Attack models
There are many different attack models to consider. A common, though misguided, mental model of a secure cryptosystem is one where the attacker gets to see a single message of modest length. If the attacker can decrypt it, then the system is insecure; otherwise, it’s suitable for any and all purposes. That certainly is an attack that a cryptosystem should be able to defend against. But there are many other models to consider, such as the following:
- An attacker who can listen to many encrypted messages between two parties
- An attacker who can replay previously transmitted encrypted messages
- An attacker who can replay modified variants of previously transmitted encrypted messages
- An attacker who can replay modified variants of previously transmitted encrypted messages to a recipient who’s expecting only well-behaved communication and who therefore displays helpful error messages if anything goes wrong during decryption
- An attacker who can listen to the encrypted communication between two parties where some of the plaintexts are known to the attacker
- An attacker who can influence the contents of encrypted communication between two other parties

Defenses that protect against more limited adversaries may fail against more advanced adversaries.

## Issues with rolling your own crypto

It’s easy to see all of the security breaches in the news and decide to protect ourselves by building a new kind of encryption. That’s a laudable goal, but it’s misguided. Without a deep understanding of how systems have been compromised, it’s unlikely that someone would be able to design a safer system from first principles. Better to reign in that desire to build a new cryptosystem until you have broken a couple yourself. If you haven’t broken anything yet, you are likely to just repeat other people’s mistakes from the past. As the saying goes,
> Those who do not learn history are destined to have George Santayana quoted at them.

 <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>


# Bugs in the crypto can have a huge impact
Writing cryptography software isn’t like writing regular software. When writing regular software, little bugs tend to have little impacts. If you have an off-by-one bug, you could expect a small bug, for example, omitting one result on a search page. If you forget to check for null references, maybe a program crashes. But with cryptography, a small mistake may leave you with a system that encrypts and decrypts correctly for well-intentioned inputs but fails entirely when faced with malicious input. 

The developer needs to either rediscover the entire field from scratch or subject the code to the scrutiny of others with a deep understanding of the field. Just as you can’t tickle yourself, you can’t find the mistakes you’ve made that involve flaws you haven’t learned about yet. Bruce Schneier has a nice essay on [Schneier’s Law](https://www.schneier.com/blog/archives/2011/04/schneiers_law.html) that expands on this.
# Attack models
There are many different attack models to consider. A common, though misguided, mental model of a secure cryptosystem is one where the attacker gets to see a single message of modest length. If the attacker can decrypt it, then the system is insecure; otherwise, it’s suitable for any and all purposes. That certainly is an attack that a cryptosystem should be able to defend against. But there are many other models to consider, such as the following:
- An attacker who can listen to many encrypted messages between two parties
- An attacker who can replay previously transmitted encrypted messages
- An attacker who can replay modified variants of previously transmitted encrypted messages
- An attacker who can replay modified variants of previously transmitted encrypted messages to a recipient who’s expecting only well-behaved communication and who therefore displays helpful error messages if anything goes wrong during decryption
- An attacker who can listen to the encrypted communication between two parties where some of the plaintexts are known to the attacker
- An attacker who can influence the contents of encrypted communication between two other parties

Defenses that protect against more limited adversaries may fail against more advanced adversaries.

# Issues with rolling your own crypto

It’s easy to see all of the security breaches in the news and decide to protect ourselves by building a new kind of encryption. That’s a laudable goal, but it’s misguided. Without a deep understanding of how systems have been compromised, it’s unlikely that someone would be able to design a safer system from first principles. Better to reign in that desire to build a new cryptosystem until you have broken a couple yourself. If you haven’t broken anything yet, you are likely to just repeat other people’s mistakes from the past. As the saying goes,
> Those who do not learn history are destined to have George Santayana quoted at them.

 <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>


Crypto is very sensitive and is best left in the hands of experts. Let's explore that in this lesson.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

Don’t Roll Your Own Crypto

Bugs in the crypto can have a huge impact