Slide 1

Slide 1 text

Build Security In Chris Cornutt - @enygma Sunshine PHP 2017.02 composer create-project enygma/sunphp17 app

Slide 2

Slide 2 text

“Secure from the start”

Slide 3

Slide 3 text

Security is not 100% Security is not an “add on” Security is not as hard as you think…

Slide 4

Slide 4 text

Risk Not just a four letter word…

Slide 5

Slide 5 text

Basic Concepts

Slide 6

Slide 6 text

Threat Modeling Threat modeling is a procedure for optimizing network security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. - searchsecurity.techtarget.com Sounds complicated, right? It’s not.

Slide 7

Slide 7 text

Threat Modeling Entity People Other systems Remote sites Process Components Internal services Command line tools Data Flow Function calls Network traffic Data Store Database Files Registry Trust Boundary Where data changes hands

Slide 8

Slide 8 text

Threat Modeling Web App Browser MySQL Database

Slide 9

Slide 9 text

Threat Modeling Web App Browser MySQL Database

Slide 10

Slide 10 text

Threat Modeling Web App Browser MySQL Database REST Interface Stripe API

Slide 11

Slide 11 text

Least Privilege In information security, computer science, and other fields, the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose. - Wikipedia

Slide 12

Slide 12 text

Least Privilege - Start at “nothing” and work up - Going from very open to closed is much harder - Makes audits so much easier

Slide 13

Slide 13 text

Least Privilege Anonymous “User” HR group HR group admin Administrator Super Administrator

Slide 14

Slide 14 text

Separation of Privilege In computer programming and computer security, privilege separation is a technique in which a program is divided into parts which are limited to the specific privileges they require in order to perform a specific task. This is used to mitigate the potential damage of a computer security attack. - A generic “user” is okay, but don’t let them run amok - Different kinds of “users”? - Should the admin even be in the same application?

Slide 15

Slide 15 text

Economy of Mechanism One factor in evaluating a system's security is its complexity. If the design, implementation, or security mechanisms are highly complex, then the likelihood of security vulnerabilities increases. Subtle problems in complex systems may be difficult to find, especially in copious amounts of code. For instance, analyzing the source code that is responsible for the normal execution of a functionality can be a difficult task, but checking for alternate behaviors in the remaining code that can achieve the same functionality can be even more difficult. One strategy for simplifying code is the use of choke points, where shared functionality reduces the amount of source code required for an operation. Simplifying design or code is not always easy, but developers should strive for implementing simpler systems when possible. - US-CERT (Computer Emergency Readiness Team)

Slide 16

Slide 16 text

Economy of Mechanism One factor in evaluating a system's security is its complexity. If the design, implementation, or security mechanisms are highly complex, then the likelihood of security vulnerabilities increases. Subtle problems in complex systems may be difficult to find, especially in copious amounts of code. For instance, analyzing the source code that is responsible for the normal execution of a functionality can be a difficult task, but checking for alternate behaviors in the remaining code that can achieve the same functionality can be even more difficult. One strategy for simplifying code is the use of choke points, where shared functionality reduces the amount of source code required for an operation. Simplifying design or code is not always easy, but developers should strive for implementing simpler systems when possible. - US-CERT (Computer Emergency Readiness Team)

Slide 17

Slide 17 text

Economy of Mechanism - Keep it Simple (Stupid) - Don’t Reinvent, Reuse - “What if”s are dangerous - Think MVSP (Minimum Viable Security Protection)

Slide 18

Slide 18 text

Complete Mediation A software system that requires access checks to an object each time a subject requests access, especially for security-critical objects, decreases the chances of mistakenly giving elevated permissions to that subject. A system that checks the subject's permissions to an object only once can invite attackers to exploit that system. If the access control rights of a subject are decreased after the first time the rights are granted and the system does not check the next access to that object, then a permissions violation can occur. Caching permissions can increase the performance of a system, but at the cost of allowing secured objects to be accessed. - US-CERT (Computer Emergency Readiness Team)

Slide 19

Slide 19 text

Complete Mediation A software system that requires access checks to an object each time a subject requests access, especially for security-critical objects, decreases the chances of mistakenly giving elevated permissions to that subject. A system that checks the subject's permissions to an object only once can invite attackers to exploit that system. If the access control rights of a subject are decreased after the first time the rights are granted and the system does not check the next access to that object, then a permissions violation can occur. Caching permissions can increase the performance of a system, but at the cost of allowing secured objects to be accessed. - US-CERT (Computer Emergency Readiness Team)

Slide 20

Slide 20 text

Complete Mediation - Check every time, don’t assume - Security through obscurity - Think about the security of the data/functionality - Weigh performance against enforcement

Slide 21

Slide 21 text

Least Common Mechanism - Endpoints shared between users - Protected according to access level - Does it show more for admins? - Split versus combined

Slide 22

Slide 22 text

Psychological Acceptability Accessibility to resources should not be inhibited by security mechanisms. If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms. Where possible, security mechanisms should be transparent to the users of the system or at most introduce minimal obstruction. Security mechanisms should be user friendly to facilitate their use and understanding in a software application. - US-CERT (Computer Emergency Readiness Team)

Slide 23

Slide 23 text

Psychological Acceptability Accessibility to resources should not be inhibited by security mechanisms. If security mechanisms hinder the usability or accessibility of resources, then users may opt to turn off those mechanisms. Where possible, security mechanisms should be transparent to the users of the system or at most introduce minimal obstruction. Security mechanisms should be user friendly to facilitate their use and understanding in a software application. - US-CERT (Computer Emergency Readiness Team)

Slide 24

Slide 24 text

Psychological Acceptability - Transparent security - Usability vs Security (constant struggle) - Example: 2FA - Example: Reauthentication - Secure defaults, then disable

Slide 25

Slide 25 text

Who’s ready for a break?

Slide 26

Slide 26 text

composer create-project enygma/sunphp17 ./setup

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

Authentication

Slide 29

Slide 29 text

Authentication Proof of Identity

Slide 30

Slide 30 text

Authorization

Slide 31

Slide 31 text

Authorization Proof of Access

Slide 32

Slide 32 text

Secure State

Slide 33

Slide 33 text

Secure State Safe Storage

Slide 34

Slide 34 text

Secure State Prevention and Protection

Slide 35

Slide 35 text

Input Validation

Slide 36

Slide 36 text

Input Validation Proof of Validity

Slide 37

Slide 37 text

Output Escaping

Slide 38

Slide 38 text

The Aftermath

Slide 39

Slide 39 text

Thanks! Chris Cornutt @enygma https://websec.io https://securingphp.com https://joind.in/talk/8cf8b