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

## Good patching practices
When defending ourselves against the risks implicit in third-party libraries, we need to know **what third-party software we use**. It takes a surprisingly large amount of effort to discover this.

Once we know what’s in use, we need the **ability to quickly upgrade** any of the third-party libraries and any software deployed in our organization. 

What’s more, we need to be able to **test these upgrades** so that we can be confident that the upgrade won’t break anything. 

We’ll want to **automate this as much as possible** because we need to do it often, and we need to do it correctly. Infrequently done manual upgrades are unlikely to work when under extreme stress and at the hurried pace likely to accompany a critical, newly discovered vulnerability. 
Finally, we need to be able to **do it on short notice** because we don’t know when we’ll need to upgrade.

## Dependencies need to be current
In order to be ready to upgrade, we need to be relatively current with our dependencies. We can’t remain on old, unsupported versions of software, even if the old versions are functionally sufficient. 

Being out-of-date is likely to cause trouble when a vulnerability is found. If we’re a couple of years out-of-date on a library and a vulnerability is announced in that library, we risk that the fix for that vulnerability will only be available in the latest version of the library. 

There could be breaking changes between our old, vulnerable version of that library and the current version. This puts us in a bad situation, where we’re unable to upgrade to a fixed version, even though we know there is a vulnerability in the version we’re using.

## Looking ahead

We’ll start by looking at patching and then look at the impact of a real-life patching mistake. Then, we’ll take an inventory of three kinds of third-party software that we use libraries we build our software with, networked software listening on our network, and operating systems. 

Inventory in hand, we’ll look at how to find published vulnerabilities in that software. We’ll wrap up the chapter by outlining the testing we’ll need to have in place in order to upgrade quickly.

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

# Good patching practices
When defending ourselves against the risks implicit in third-party libraries, we need to know **what third-party software we use**. It takes a surprisingly large amount of effort to discover this.

Once we know what’s in use, we need the **ability to quickly upgrade** any of the third-party libraries and any software deployed in our organization. 

What’s more, we need to be able to **test these upgrades** so that we can be confident that the upgrade won’t break anything. 

We’ll want to **automate this as much as possible** because we need to do it often, and we need to do it correctly. Infrequently done manual upgrades are unlikely to work when under extreme stress and at the hurried pace likely to accompany a critical, newly discovered vulnerability. 
Finally, we need to be able to **do it on short notice** because we don’t know when we’ll need to upgrade.

# Dependencies need to be current
In order to be ready to upgrade, we need to be relatively current with our dependencies. We can’t remain on old, unsupported versions of software, even if the old versions are functionally sufficient. 

Being out-of-date is likely to cause trouble when a vulnerability is found. If we’re a couple of years out-of-date on a library and a vulnerability is announced in that library, we risk that the fix for that vulnerability will only be available in the latest version of the library. 

There could be breaking changes between our old, vulnerable version of that library and the current version. This puts us in a bad situation, where we’re unable to upgrade to a fixed version, even though we know there is a vulnerability in the version we’re using.

# Looking ahead

We’ll start by looking at patching and then look at the impact of a real-life patching mistake. Then, we’ll take an inventory of three kinds of third-party software that we use libraries we build our software with, networked software listening on our network, and operating systems. 

Inventory in hand, we’ll look at how to find published vulnerabilities in that software. We’ll wrap up the chapter by outlining the testing we’ll need to have in place in order to upgrade quickly.

<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'll look at good practices when it comes to patching and briefly walkthrough what this chapter holds.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

Upgrading Third-Party Libraries and Software

Good patching practices