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

## OWASP Dependency-Check
OWASP has a free, open-source tool called [Dependency-Check](https://www.owasp.org/index.php/OWASP_Dependency_Check) that can help automate the detection of vulnerable third-party libraries. This tool supports Java and .NET, with experimental support for Ruby, Node.js, Python, and C/C++ codebases. One of the nice features of this tool is that it can parse project files that you probably already use for managing your builds, such as pom.xml files in Java codebases and .nuspec files in .NET codebases. So it leverages the work you have already done in order to figure out your dependencies: you do not have to map out your dependencies specifically for the tool. Once it has parsed out the dependencies, it queries the CVE database (which we discuss in [What Is a CVE?](https://www.educative.io/courses/practical-security-defending-your-systems/a-closer-look-at-patching#patching-and-the-equifax-breach)) to see if any of the libraries you use have published vulnerabilities. This tool is meant to run during your build process. That way, you can fail builds that use vulnerable libraries and stop vulnerable libraries from even making it into your test environments.

## Detecting vulnerable libraries in your source repository

There are also commercial solutions that integrate more closely with your source control and build artefact repositories. For some organizations, this may be an easier point at which to automate library vulnerability detection. 

Two examples are [JFrog’s Xray](https://jfrog.com/xray/) and GitLab’s [Auto Dependency Scanning]( https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-dependency-scanning-ultimate). These tools work similarly: During your build process, they look for vulnerabilities in the libraries you depend on. If they find any, they can fail your build. So you do not even have the opportunity to ship with vulnerable libraries.

The important thing is not really which tool you pick, but that somewhere in your development process you have a step that catches use of vulnerable libraries. Run this step automatically if you can, manually if you must.


---
In the next lesson, we'll get an introduction to taking inventory of all the networked software running on the network.

# OWASP Dependency-Check
OWASP has a free, open-source tool called [Dependency-Check](https://www.owasp.org/index.php/OWASP_Dependency_Check) that can help automate the detection of vulnerable third-party libraries. This tool supports Java and .NET, with experimental support for Ruby, Node.js, Python, and C/C++ codebases. One of the nice features of this tool is that it can parse project files that you probably already use for managing your builds, such as pom.xml files in Java codebases and .nuspec files in .NET codebases. So it leverages the work you have already done in order to figure out your dependencies: you do not have to map out your dependencies specifically for the tool. Once it has parsed out the dependencies, it queries the CVE database (which we discuss in [What Is a CVE?](https://www.educative.io/courses/practical-security-defending-your-systems/a-closer-look-at-patching#patching-and-the-equifax-breach)) to see if any of the libraries you use have published vulnerabilities. This tool is meant to run during your build process. That way, you can fail builds that use vulnerable libraries and stop vulnerable libraries from even making it into your test environments.

# Detecting vulnerable libraries in your source repository

There are also commercial solutions that integrate more closely with your source control and build artefact repositories. For some organizations, this may be an easier point at which to automate library vulnerability detection. 

Two examples are [JFrog’s Xray](https://jfrog.com/xray/) and GitLab’s [Auto Dependency Scanning]( https://docs.gitlab.com/ee/topics/autodevops/index.html#auto-dependency-scanning-ultimate). These tools work similarly: During your build process, they look for vulnerabilities in the libraries you depend on. If they find any, they can fail your build. So you do not even have the opportunity to ship with vulnerable libraries.

The important thing is not really which tool you pick, but that somewhere in your development process you have a step that catches use of vulnerable libraries. Run this step automatically if you can, manually if you must.


---
In the next lesson, we'll get an introduction to taking inventory of all the networked software running on the network.

In this lesson, we will explore a few tools that automatically detect vulnerabilities in source code​, including the OWASP Dependency-Check tool.

Introduction

Patching

Vulnerabilities

Cryptography

Windows

Phishing

Automating Vulnerability Detection

OWASP Dependency-Check