Added Sections For Zero Trust and Defense In Depth in SSDLC module

modules/3-ssdlc.livemd

@@ -9,7 +9,13 @@ Welcome to Part 3! This section is dedicated to discussing some of the more abst
 * [No Secrets In Code](#no-secrets-in-code)
 * [Making Secret Rotation Easy](#making-secret-rotation-easy)
 * [Rate Limiting](#rate-limiting)
-* [Principle of Least Privilege](#principle-of-least-privlege)
+* [Zero Trust Model](#zero-trust-model)
+  * [Principle of Least Privilege](principle-of-least-privlege)
+  * [Device Access Control](device-access-control)
+  * [Microsegmentation](microsegmentation)
+  * [Preventing Lateral Movement](preventing-lateral-movement)
+  * [Multi Factor Authentication](multi-factor-authentication)
+* [Defense In Depth](#defense-in-depth)
 
 ## No Secrets In Code
 
@@ -75,18 +81,86 @@ If the answer to one or more of those questions is yes, consider putting a limit
 
 More often than not, rate limiting should be as specific as possible. For instance, it is better to add rate limiting on a single GraphQL type than to add a generic limit to the entire /GraphQL endpoint.
 
-## Principle of Least Privilege
+## Zero Trust Model
+
+### Principle of Least Privilege
 
 Sometimes known as the Principle of Minimal Privilege or the Principle of Least Authority, the Principle of Least Privilege (PoLP) means that every entity* is only strictly given the essential privileges needed to perform its requirement.
 
 E.g. A script that executes on a cron schedule that monitors the output of a log file only needs read privileges and should not be given write privileges.
 
 **Entity: generic term for an arbitrary process, user, program, etc. found within a Data System*
 
-### Benefits of the Principle
+#### Benefits of the Principle
 
 * **Better Data System Stability** - When an entity is limited in the scope of changes it can make to a system, it is easier to test its possible actions and interactions in the context of the Data System.
 * **Better Data System Security** - When an entity is limited in the system-wide actions it may perform, vulnerabilities / compromises in one application cannot be used to exploit the rest of the business or adjacent Data Systems.
 * **Ease of Deployment** - In general, the fewer privileges an entity requires, the easier it is to deploy within a larger environment.
   <br /><br />
-  [**<- Previous Module: OWASP**](./2-owasp.livemd) || [**Next Module: GraphQL Security ->**](./4-graphql.livemd)
+
+### Device Access Control
+
+Zero Trust is not only about controlling user access, but requires strict controls on device access as well. With this, Zero Trust systems need to monitor how many different devices are trying to access their network, ensure that every device is authorized, and assess all devices to make sure they have not been compromised. This further minimizes the attack surface of the network.
+
+### Microsegmentation
+
+Microsegmentation is the practice of breaking up security perimeters into small zones to maintain separate access for separate parts of the network. Some of the benefits of doing so are: 
+* Granular Access Policies- we can create super specific policies for access to each segment! 
+* Targeted Security Controls - we can develop each micro-perimeter to specifically target the security risks and vulnerabilities of the resources in that micro-segment! 
+* Establishing Identities and Trust - we can implement, monitor, and control the “never trust, always verify” principle much easier! 
+
+### Preventing Lateral Movement 
+
+Zero Trust is designed to contain attackers so that they can not move laterally. You may be asking what does that even mean? In network security, “lateral movement” is when an attacker moves within a network after gaining access to it, which can be very difficult to detect. 
+
+Zero Trust helps contain attackers because the access is segmented and has to be reestablished periodically, limiting them from moving across to other microsegments within the network. 
+
+### Multi Factor Authentication
+
+It's no surprise that MFA is a core part of the Zero Trust Model. Systems using MFA require more than one piece of evidence to authenticate a user, with the most common form being a one time password (OTP). 
+
+### Reference
+1. https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/
+
+## Defense In Depth
+
+Defense in depth is a security approach of having defense mechanisms in a layered approach to protect valuable assets. Castles take a similar approach, where they have a moat, ramparts, towers, and drawbridges instead of just one wall as protection. 
+
+An example of developing a web application using defense in depth could be: 
+* The developers (like yourself) receive secure coding training
+* The codebase is checked automatically for vulnerabilities using Semgrep
+* The codebase is also checked for outdated dependencies using Dependabot
+* The application is regularly tested by the internal security team 
+* Multiple development environments are used such as Develpoment, Staging, and Production
+
+<br> </br> 
+
+Using more than one of the following layers constitutes an example of defense in depth: 
+
+### System and Application 
+
+* Authentication and password security
+  * Hashing passwords 
+  * Multi factor authentication (MFA) 
+* Encryption 
+* Security Tooling 
+* Security Awareness Training (sounds familiar 😉) 
+* Logging and Monitoring 
+
+### Network 
+
+* Firewalls (hardware and software) 
+* Demilitarized zones (DMZ) 
+* Virtual Private Networks (VPN)
+
+### Physical 
+
+* Biometrics 
+* Data-centric security 
+* Physical Security (such as locked server rooms) 
+
+### Reference
+1. https://www.forcepoint.com/cyber-edu/defense-depth
+
+
+[**<- Previous Module: OWASP**](./2-owasp.livemd) || [**Next Module: GraphQL Security ->**](./4-graphql.livemd)

modules/5-elixir.livemd

@@ -13,10 +13,11 @@ But even the dullest blades can hurt someone! This module goes over Elixir speci
 ## Table of Contents
 
 * [Atom Exhaustion](#atom-exhaustion)
-* [Protecting Sensitive Data](#protecting-sensitive-data)
+* [Serialization and Deserialization](#serialization-and-deserialization)
 * [Untrusted Code](#untrusted-code)
 * [Timing Attacks](#timing-attacks)
 * [Boolean Coercion](#boolean-coercion)
+* [Protecting Sensitive Data](#protecting-sensitive-data)
 
 ## Atom Exhaustion
 
@@ -61,6 +62,22 @@ IO.puts("Are you protected against Atom Exhaustion?")
 IO.puts(:erlang.system_info(:atom_count) == prev_count)
 ```
 
+## Serialization and Deserialization
+
+### Description
+
+Deserialization of untrusted input can result in atom creation, which can lead to your application being vulnerable to denial of service (DOS) attacks. When you do use a deserialization library, make sure that the library does not create arbitrary atoms: either configure the library to return strings/binaries or enable schema validation to constrain the input
+
+### Prevention
+
+* Use the :safe option when calling :erlang.binary_to_term/2 on untrusted input (should be familiar from atom exhaustion 😀)
+* Prevent function deserialisation from untrusted input, e.g. using Plug.Crypto.non_executable_binary_to_term/1,2
+
+### Resources
+
+1. https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/serialisation
+
+
 ## Untrusted Code
 
 ### Description
@@ -204,4 +221,45 @@ user_input = "some_string_which_obviously_isnt_the_same_as_the_password"
 # if SecurityCheck.validate(user_input, password) || raise(SecurityCheck) do :you_let_a_baddie_in end
 ```
 
+## Protecting Sensitive Data
+
+### Description
+
+Sensitive data is any information that should be out of reach from all outsiders unless they have permission to access it, which in most cases would be considered "confidential data". Some examples of sensitive data are PHI (Protected Health Information) or PII (Personally Identifiable Information).
+
+### Prevention
+
+I think we can all agree that making sure this information is secure is important, but let's dive into how to actually protect it:
+
+## Wrapping
+
+Exceptions may result in console or log output that includes a stack trace. Mostly a stack trace shows the module/function/arity and the filename/line where the exception occurred, but for the function at the top of the stack the actual list of arguments may be included instead of the function arity.
+To prevent sensitive data from leaking in a stack trace, the value may be wrapped in a closure: a zero-arity anonymous function. The inner value can be easily unwrapped where it is needed by invoking the function. If an error occurs and function arguments are written to the console or a log, it is shown as #Fun<...> or #Function<...>. Secrets wrapped in a closure are also safe from introspection using Observer and from being written to crash dumps.
+
+### <span style="color:blue;">Example</span>
+
+```elixir
+wrapped_secret = fn -> System.get_env("SECRET") end
+```
+
+## Stacktrace Pruning
+
+Another approach, useful in functions that call the standard library (e.g. crypto) or other functions that do not support wrapping secrets in a closure, is stripping argument values from the stack trace when an exception occurs. This can be done by wrapping the function call(s) in a try … catch expression (Erlang) or adding a rescue clause to a function body (Elixir), and stripping the function arguments before re-raising the exception:
+
+## ETS Tables
+
+ETS tables can be declared as ‘private’ (:private option), preventing the table from being read by other processes, such as remote shell sessions. Private tables are also not visible in ‘observer’.
+
+### <span style="color:red;">Quiz</span>
+
+** We have decided that we do not want this ETS table to be read from other processes, so try making it private:
+
+```elixir
+cool_table = :ets.new(:cool_table, [])
+```
+
+## Reference
+
+1. https://erlef.github.io/security-wg/secure_coding_and_deployment_hardening/sensitive_data.html
+
 [**<- Previous Module: GraphQL Security**](./4-graphql.livemd) || [**Next Module: Cookie Security ->**](./6-cookies.livemd)