Join our our deep dive discussion on the following OWASP Projects ranging from Incubator to flagship projects. We welcome students and contributors to jump right in and work live with project leaders. Project Reviews will also be conducted throughout the Two Day Session of the Project Summit.
Current OWASP Projects Signed Up:
Presenting on 9/19 @ 1:00 pm (45 min) CISO Application Security Guide and Survey Project
Presenting on 9/20 OWASP Core Rule Set Project
Presenting on 9/20 @ 3:00 pm - OWASP Virtual Village Project Resource
Presenting on 9/20 @ 10:00 AM - OWASP DefectDojo Project
Current OWASP Project Reviews Scheduled:
OWASP Security Knowledge Framework Project
OWASP Security Mobile Testing Guide Project
OWASP Lab/Incubator Projects Deep Dive Health Checks
We would like your feedback and offer a unique opportunity to discuss hot topics.
Currently on the list of topics: (Open to more hot topics)
Resources for Projects
Reimbursement Form & Process
Discourse
Kickstarter Pilot Program
Please use our contact us form with any questions or concerns. Contacts at OWASP Foundation: Matt Tesauro and Claudia Aviles Casanovas will be onsite as well.
Class Summary: This hands on, two (2) day class will help students learn how to write hardened ASP.NET based web services. Day one (1) will start off with the very basics of C# and Visual studio and slowly progress through a variety of topics as they pertain to web service hardening. On day two (2), students will dive into standard web service security, and end with trainees writing their own secure service for a fictional project. Individuals who meet the requirements and write a working hardened web service, are entered into a prize drawing.
Syllabus:
1. Day One (1) –Fundamentals
a. Visual Studio – Quick Rundown
i. IDE Basics
ii. C# Hello World
b. Basics of Object Oriented Programming
c. Useful 3rd Party Libraries
i. JSON.NET (Newtonsoft.Json)
ii. PushSharp
iii. BouncyCastle
d. Basic Web Service writing
i. Bindings
ii. Database design (quick tutorial)
iii. SOAP Services
iv. RESTful Services
e. Basic Service Security
i. Response Encapsulation
ii. Input validation and Sanitizing
iii. XXE, SQLi, and ‘XSS’ mitigation
f. Transport Security
i. SSL
ii. Binding Parameters
g. Message Security
i. Credential Types
ii. Encryption
iii. Certificates
2. Day Two (2) – Intermediate Service Security
a. Replay Attacks
b. Cross Site Request Forgery
c. WS-Security (SOAP Services)
d. Signature Based Security (RESTful Services)
e. Performance and usability vs Security
f. Afternoon Hardened Web Service Development
Experience: This would be the first class I’ve taught on a national scale. I’ve taught people individually on both coding, and penetration testing. I served as an adjunct teacher while in High School and in College.
After immensely successful workshops in the Bay Area, Bangalore, AppSecEU 2017 and record, sold-out workshop at the OWASP AppSecUSA 2016 in Washington D.C., we bring to you a new avatar of the Hands-on Security in DevOps workshop, this time, with some focused content on Application Security Automation.
Agile and DevOps have revolutionized the way we deliver apps to customers. Software products today demand rapid everything. Rapid Code Changes, Rapid Deployments and Rapid Delivery. In addition, you have embraced Agile Development Methodologies that stress on iterative product development and flexibility to changing environments. There is one major problem in this entire chain, and that is Application Security.
While your product may be rapidly delivered to customers, Application security still remains a massive bottleneck in your continuous delivery pipeline. Application security is critical because companies lose billions of dollars due to vulnerabilities in their applications. Apart from typical vulnerabilities like SQL Injection and Cross Site Scripting, vulnerabilities in authentication, authorization, business logic and cryptographic implementations are more prevalent and can cause massive damage to a software product company.
This is why you need SecDevOps. You need a practical, repeatable and scalable way to deliver Application Security to your product across the Agile and DevOps lifecycle. In this workshop you will receive powerful hands on training on how you can implement scalable and effective security for rapid-release applications. The workshop will be a hardcore hands-on workshop with coverage on the following, but not limited to:
¥ Static Application Security Testing - Integrated with Continuous Integration Services
¥ Rolling out Custom SAST – using Abstract Syntax Trees and Regular Expressions
¥ Customized Security Automation Scripting Framework with Continuous Integration
¥ Creating specialized Application Security Testing Scripts to be integrated with existing Test Suites
¥ Performing Automated, Authenticated and Parameterized Vulnerability Assessments against Web Apps and Web Services by hacking tools like ZAP and w3af
¥ Automation Scripting for Application Security Vulnerability Scanners – OWASP ZAP Custom Scripts – Active Scanning, HTTPSender, Proxy Scripts, with an introduction to Zest Scrits. MITMproxy Inline Scripting
¥ An Introduction to Behavior Driven Security Testing
¥ Parameterized Security Testing for Web Services using the OpenAPI Specification
¥ Security in Configuration management and Continuous Deployment
¥ Security Practices and Considerations for Docker Deployments
¥ Creating Security Configuration Management “Infrastructure as Code” and Validation Scripts – using Ansible
¥ Practical Threat Modeling in an Agile and DevOps world
This full-fledged hands-on training will get the attendees familiar with the various Android as well as iOS application analysis techniques and bypassing the existing security models in both the platforms.
The main objective of this training is to provide a proper guide on how the mobile applications can be attacked and provide an overview of how some of the most important security checks for the applications are applied and get an in-depth understanding of these security checks.
The workshop will also include a CTF challenge designed by the trainer in the end where the attendees will use their skills learnt during the workshop to solve this challenge.
This training will mainly focus on the following :
> Arm basics and Android native code.
> Reverse engineer Dex code for security analysis.
> Jailbreaking/Rooting of the device and also various techniques to detect Jailbreak/Root.
> Runtime analysis of the apps by active debugging.
> Modifying parts of the code, where any part can be specified as some functions, classes and to perform this check or to identify the modification, we will learn how to find and calculate the checksum of the code. Our objective in this section will be to learn, Reverse Engineering an application, get its executable binaries , modify these binaries accordingly, resign the application.
> Runtime modification of code. Objective is to learn how the programs/codes can be changed or modified at runtime. we will learn how to perform introspection or overriding the default behavior of the methods during runtime and then we will learn how to identify if the methods have been changed). For iOS we can make use of tool Cycript, snoop-it etc.
> Hooking an application and learn to perform program/code modification.
> By the end of workshop, based on the course content CTF challenges written by the trainer will be launched, where the attendees will use their skills learnt in the workshop to solve the CTF challenges. The workshop will begin with a quick understanding on the architecture, file system,permissions and security model of both iOS and Android platform.
NOTE:
The tools and techniques used in the workshop are all open source and no special proprietary tools need to be purchased by the attendees for analysis post the training. Some of the tools taught in the training will be helpful in analysis and automating test cases for security testing of the mobile apps:
Drozer
Introspy
Apktool
Dex2jar
Cycript
JD-Gui
SSL Trust killer
Open Source Defensive Security Training is an Open Source IT Security laboratory dedicated for professionals who need close the gaps in Linux, Web application & Open Source Security knowledge. Very detailed and up to date course content with focus especially on defensive approach gives you the best opportunity for making stronger defensive layers inside your network infrastructures or/and Linux-based products. Delivering a real world scenarios in our Open Source Defensive Security hands-on labs provide a very practical knowledge you need for expand your Linux Security skills.
This is an extremely deep dive training on Open Source-based infrastructure security, Linux systems and network services hardening. We like details as attackers do and that details bring the differences - from offensive and defensive approach. That's how we see it works. Our high-tech workshop has a unique formula “protection vs attack”. This means that most of the security issues we are talking about will be effectively protected by the use of a suitable approach, sophisticated software and dedicated secure configuration. We focus on delivering a defensive content, but we understand that for being good in defense you have to also be good in offense. That way we are providing a kind of knowledge-mix in those fields using Open Source software. Except basic Linux skills and TCP/IP knowledge, most of the lab exercises required of candidate at least basic understanding of what attacker techniques are. We strongly believe that only a mix of broad, systematic Defensive and Offensive Security knowledge can guarantee secure solutions. As Sun Tzu said: "Know your enemy and know yourself and you can fight a hundred battles without disaster."
The workshop has prepared the following examples of laboratory scenarios:
● Web Application Security vs OWASP Top 10 attack techniques and others
● Grsecurity/PAX/GCC hardening vs Linux kernel and userspace exploitation using vulnerabilities from the last past years (PERF_EVENTS, ptrace/sysret, memppodiper, semtex, sendpage, chroot() escape, dirty_cow, others)
● Seccomp/capabilities/namespaces vs exploits
● SELinux vs exploits (Redis Command Execution, Venom, Apache)
● Volatility vs rootkits
● Secure SSH relays and importance of low level privileges rule
● System users accountability, including root
● Linux Domain Controller
● Using sysdig/SystemTAP for detecting deviations in the behavior of daemons and services ● Network packet filtering including TOR, ipsets, IP reputation, port knocking
● Network honeypots vs scanning tools and obstruction of the process of enumeration
● PCAP analysis and Deep Packet Inspection vs malware
● Sandboxing for malware detection and deep analysis (cuckoo, yara) and others
Target:
● Linux administrators & System Architects
● IT Security professionals
● Penetration testers
● IT Security consultants and Open Source specialists
Thanks to this training you will:
● learn techniques to protect your Linux systems against attacks used by modern attackers
● find out how you can protect Linux servers and web applications against real attacks
● learn how to use dozens of solutions and security tools for offensive and defensive scope
● configure several advanced solutions to reduce the success of the attack or minimize the risk of the use of vulnerability
True values:
● real life, 100% pure lab-oriented defensive security scenarios
● minimum theory, maximum hands-on
● a lot of cumulated knowledge in one place
● created by enthusiasts and professionals for professionals with enthusiasm
Agenda:
1. Threats are everywhere - introduction to technical Open Source Defensive Security program.
2. Web application security -> hardened Reverse Proxy -> modsecurity vs HTTP security issues:
● Analysis and practical use of exploits for popular web applications: Jenkins, Zimbra, PHPnuke, Joomla, Drupal, PHPmyadmin, OScommerce, Magento, Wordpress, dotProject and others
● Authorization and authentication: CAS SSO, OAuth, SAML (ipsilon), Federation, Basic / Digest Auth, SSL authentication, LDAP authorization, SAML based - mod_auth_mellon, Kerberos based - mod_auth_kerb, Login-form based - mod_intercept_form_submit, Mod_lookup_identity, mod_pubcookie
●HTTPS – how to achieve status A+?:
○ Attacks:
■ Heartbleed
■ Breach
■ Drown
■ Beast
■ Poodle
■ MiTM: sslstrip
○ Mutual SSL
● Security headers: Content Security Policy, Cross Origin Resource Sharing / Same Origin Policy, X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Fetch API, Service Workers, Sub_resource Integrity, Per-page sub-origins, Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), Same Origin Policy (SOP) / Cross Origin Resource Sharing (CORS), HPKP, PFS
● Cookies: Secure, Httponly, Domain, Path, Same_site, Clear Site Data Feature Policy, First-party cookies
● HTTP header anomalies Virtual patching
● Full HTTP auditing
● LUA/OpenResty support
● Sensor approach - OWASP Appsensor
● Web application security using Modsecurity - creating dedicated WAF rules against:
■ *Injections
■ Null bytes
■ Path/directory traversal
■ LFI/RFI->Command Execution
■ Cross Site Scripting (XSS)
■ Cross Site Request Forgery (CSRF)
■ HTTP Parameter Pollution (HPP)
■ Open Redirect
■ Insecure Direct Object Reference vs HMAC
■ Forceful Browsing
■ CSWSH - Cross Site Websocket Hijacking
■ Session Security
■ Brute force
■ Slow DOS
■ GEO restrictions
■ Error handling
■ Leakage detection
■ Secure file upload
■ Secure logout / forgot password form
■ Web honeypots
■ Bot/scan protection
■ AV protection
■ PHP Security
■ Tomcat Security
■ Tools:
● Sqlmap, sqlninja
● Xsser
● Dominator
● Skipfish
● ZAP / Burp
● Wafdetect
● Joomscan, wpscan
● Dirbuster, dirb
● Nikto
● JSDetox
● Brakeman
● And others
3. Hardened Linux vs exploits/rootkits:
● Discretionary Access Control (DAC) vs Mandatory Access Control (MAC)
● Grsecurity / PAX
● SELinux / Multi Category Security / sVirt
● Apparmor, Tomoyo, Smack, RSBAC
● GCC hardening: SSP, NX, PIE, RELRO, ASLR vs attacks
● Linux Containers - Docker/LXC
● LKM-off / YAMA / enforcing
● Linux capabilities vs SUID and others
● System call restriction - seccomp
● Integrity checking - IMA/EVM
● Package mgmt security
● Debuggers and profilers - gdb/strace/ldd/Valgring/Yara
● Chroot/jail/pivot_root
● Behavioral analysis - systemtap / LTTng / sysdig
● Memory forensics - Volatility vs malware
● PAM / 2FA
● System update vs reboot
● *privchecks
4. Network security:
● Vulnerability scanning:
● Nmap NSE
● Seccubus
● OpenVAS
● Metasploit
● Linux Domain Controller - IdM/HBAC/SUDO
● SFTP/SCP - Secure SSH Relay
● Restricted shells/commands
● SSH tips and tricks
● Public Key Infrastructure – SSL/TLS
● NFS Security
● Database Security
● DNS Security
● Mail Security
● DOS / scanning / brute-force protection techniques
● Advanced network firewall: iptables/nftables/ebtables
● System honeypots
● Network traffic analysis - wireshark, scapy / tcpdump / tcpreplay
● Suricata / Bro IDS / Snort / SELKS vs known malware and attacks:
○ Metasploit,
○ PtH,
○ Heartbleed,
○ shellshock and others
● Security by obscurity
5. System Auditing, integrating & accounting:
● *syslog
● Auditd
● OSSEC / Samhain / aide
● SIEM: Splunk/ELK/OSSIM/osquery
6. Summary: offense vs defense
Practical DevOps Security and Exploitation is a brand new and unique class by Attify. This class has been created as a result of our many pentest engagement experiences where we have exploited vulnerabilities in the various systems supporting CI/CD during DevOps transition of an organisation. The class covers hands-on techniques to both exploit as well as defend various systems that support the target CI/CD Architecture.
This class takes practitioner's approach in breaking, exploiting and securing systems owned by DevOps teams, thus enabling them to move towards DevSecOps. Some of the topics that we will cover are Exploiting Various tools from the CI/CD landscape like Jenkins, Git, Multiple Cloud instances, practical security issues in Docker instances and setting up your DevSecOps architecture.
This training covers different CI/CD tools with pentesters perspective and hence each tool will be covered as below:
This is an action packed class with over 20+ labs covering a number of attacks, vulnerabilities and exploitation tactics.
Deliverables:
After the training, attendees would be able to:
Minimum Requirements:
Practical Hands-on Internet of Things Hacking is an updated version of our previous year class ran at OWASP AppSec US. We received some great feedback with our class, and decided to take it a step further and redesign the course from the ground up and include tons of new material including medical utilities, smart locks, smart home systems, newer radio protocols, advanced exploitation techniques, new exercises on BLE and lots more
Practical Hands-on Internet of Things Exploitation is the course for you in case you would like to perform real-world pentest on IoT and smart devices. This “new version” of the course takes a practitioner approach, focusing on how to deal with the IoT devices in a real-world scenario, and not just from a research perspective.
Some of the things that we will perform (in an extremely hands-on nature) in this training are:
[+] Attacking IoT devices through hardware and embedded exploitation techniques
[+] Firmware reversing, emulation and binary exploitation
[+] Hands-on labs on serial interfaces - UART, SPI and I2C
[+] JTAG debugging, exploitation and advanced techniques for extracting data
[+] Sniffing BLE, Zigbee and other radio communications
[+] Writing own GNURadio processing blocks to decode radio information
[+] Taking over smart home systems
[+] Remote and Local Exploitation for IoT devices
[+] Attacking a smart home and smart enterprise network
And much more.
Want to learn how to attack an IoT infrastructure or individual devices? You will walk out of the 2-day class having learnt new skills which you could immediately apply in your job/research roles. Come join the course and experience the fast-paced, action-packed IoT Exploitation class.
Note: There is an additional $200 fee for the IoT hacking kit - which includes Attify Badges and custom vulnerable IoT device prepared by us, and an author signed copy of the IoT Hackers Handbook, and additional utilities for other IoT exploitation techniques.
Toreon proposes a 2 day, trainer-led, on-site, Threat Modeling course. The training material and hands-on workshops with real live Use Cases are provided by Toreon. The students will be challenged to perform practical threat modeling in groups of 3 to 4 people covering the different stages of threat modeling on:
• A hotel booking web and mobile application, sharing the same REST backend
• An Internet of Things (IoT) deployment with an on premise gateway and secure update service
• An HR services OAuth scenario for mobile and web applications
This edition also introduces a new section on privacy threats and privacy by design, including a hands-on privacy impact assessment of a face recognition system in an airport. Each student will receive a hard copy of the book: Threat Modeling, designing for security by Adam Shostack (2014, Wiley)
This training is delivered successfully at OWASP Europe 2016 and is selected for OWASP Europe 2017 and Blackhat USA 2017. More details and the outline of the training are available in the attached syllabus.
There is NO charge to attend the Developer Summit, so come join us!
We do ask that you SIGN UP so we have an estimated headcount to be sure we have enough space and food.
Half Day Morning Session
Date: Tuesday, September 19, 2017
Time: 10am-1pm
Location: Coronado N&P
Presenter: Robert Hurlbut
Using OWASP Threat Dragon for Threat Modeling
OWASP Threat Dragon is a new OWASP project that introduces a threat modeling tool that is portable (able to be used on the web in various platforms), integrates well with build process, and is a great tool to introduce to developers and teams. This developer hands-on session will focus on introducing the Threat Dragon tool, best ways to use the tool in a day-to-day developer environment, and making it part of the CI implementation (including integration with Jenkins, etc.).
What will be discussed?
What will attendees learn from attending this session?
Items attendees are required to bring with them
There is NO charge to attend the Developer Summit, so come join us!
We do ask that you SIGN UP so we have an estimated headcount to be sure we have enough space and food.
Half Day Afternoon Session
Date: Tuesday, September 19, 2017
Time: 2pm-5pm
Location: Coronado N&P
Presenters: Nicole Becher and Tanya Janca
Hacking APIs and Web Services with OWASP DevSlop & PIXI!
Modern applications often use APIs and other micro services to deliver faster and better products and services. However, there are currently few training grounds for security testing in such areas. In comes DevSlop, OWASP's newest project, a collection of DevOps security disasters made as a vulnerable testing and proving ground for developers and security testers alike. DevSlop's Pixi, the first of many entries to come for this OWASP project, will be demonstrated and presenting for participant's hacking and learning pleasure. Pixi consists of vulnerable web services, and participants will be walked through how to exploit several of it's vulnerabilities so they can learn how to do better when they create their own web services and other types of APIs from now on.
What will be discussed?
What will attendees learn from attending this session?
Items attendees are required to bring with them
SQL Injection (SQLi) vulnerabilities are the most common injection flaws found in web applications today, ranking number one in the OWASP Top 10 most critical web application security risks. When an attacker is able to find and exploit such a vulnerability, the end result is often disastrous: complete database download, application backdoor created or even remote code execution. Suffice to say that penetration testers need to find these vulnerabilities before the bad guys do.
But vulnerability scanners and automated exploitation tools like sqlmap can only do so much when it comes to finding and exploiting SQLi vulnerabilities. While they do a good job for regular or error-based SQLi vulnerabilities, their success rate lowers drastically when blind SQLi is encountered, especially when time-based attacks are required. And if you need to be quiet on the network, most tools are just insanely noisy…
This course is designed to help penetration testers who have been using these tools to get to the next level, where finding and exploiting SQLi is no longer easy. When only a browser and notepad are available to you or when being quiet is critical, you will be glad you know this stuff.
1) SQL crash course for hackers
2) Error-based SQL Injection
- Bypassing login (demo)
- UNION exploitation techniques (exercise)
3) Blind SQL Injection
- Splitting and Balancing
- Boolean exploitation techniques (exercise)
- Time-based exploitation techniques (exercise)
4) Using tools
- Exploiting error-based and blind SQLi using sqlmap (exercise)
The Application Security Fundamentals is an in-depth, one-day course that teaches the foundational principles of application and product security. This course is aimed at beginners or those new to application security. In class exercises are included throughout the day to generate interaction and discussion amongst students. The course is modular, and covers application security vocabulary, attacks and attackers, data breaches, business myths, the threat Landscape, software supply chain, security culture and mindset, managing security resources, soft skills, secure development lifecycle, privacy, product incident response, and trusted knowledge sources.
Developing the Defensive Application Security Program
Creating your Websites and Web Applications inventory
Defining proper Software Security controls by Application Risk
Quick Test and Quick Wins with OWASP ZAP
Selecting and using proper Static Analysis tools
Finding insecure libraries using OWASP Dependency Check
Virtual Patching of legacy applications with Mod_Security
Applying Secure-Headers automatically
Detecting malicious behavior with OWASP AppSensor
Developing and presenting the Security Dashboard
The intended audience is very broad from developers to managers, beginners to advanced users.
The length is one-day.
The students will receive the class syllabus and book.
This course is a summarized version of a six-month class taught in 3 courses of our University.
The trainer is a PhD student in Cyber-Security and professor at IFC (Catarinense Federal Institute), (ISC)2's Certified Secure Software Lifecycle Professional (CSSLP),
ISSECO® Certified Professional for Secure Software Engineering (CPSSE), ISO/IEC 27002 Foundation Certified,
ISEB/ISTQB Certified Professional e ITIL F.
Worked as Security Consultant and implementing OWASP best practices for securing software in companies like DELL, EDS (HP) and Elavon/US Bank.
Published articles at international conferences and presented at OWASP AppSec Latam, FLISOL and RoadSec between others.
Class Summary: This hands on, two (2) day class will help students learn how to write hardened ASP.NET based web services. Day one (1) will start off with the very basics of C# and Visual studio and slowly progress through a variety of topics as they pertain to web service hardening. On day two (2), students will dive into standard web service security, and end with trainees writing their own secure service for a fictional project. Individuals who meet the requirements and write a working hardened web service, are entered into a prize drawing.
Syllabus:
1. Day One (1) –Fundamentals
a. Visual Studio – Quick Rundown
i. IDE Basics
ii. C# Hello World
b. Basics of Object Oriented Programming
c. Useful 3rd Party Libraries
i. JSON.NET (Newtonsoft.Json)
ii. PushSharp
iii. BouncyCastle
d. Basic Web Service writing
i. Bindings
ii. Database design (quick tutorial)
iii. SOAP Services
iv. RESTful Services
e. Basic Service Security
i. Response Encapsulation
ii. Input validation and Sanitizing
iii. XXE, SQLi, and ‘XSS’ mitigation
f. Transport Security
i. SSL
ii. Binding Parameters
g. Message Security
i. Credential Types
ii. Encryption
iii. Certificates
2. Day Two (2) – Intermediate Service Security
a. Replay Attacks
b. Cross Site Request Forgery
c. WS-Security (SOAP Services)
d. Signature Based Security (RESTful Services)
e. Performance and usability vs Security
f. Afternoon Hardened Web Service Development
Experience: This would be the first class I’ve taught on a national scale. I’ve taught people individually on both coding, and penetration testing. I served as an adjunct teacher while in High School and in College.
After immensely successful workshops in the Bay Area, Bangalore, AppSecEU 2017 and record, sold-out workshop at the OWASP AppSecUSA 2016 in Washington D.C., we bring to you a new avatar of the Hands-on Security in DevOps workshop, this time, with some focused content on Application Security Automation.
Agile and DevOps have revolutionized the way we deliver apps to customers. Software products today demand rapid everything. Rapid Code Changes, Rapid Deployments and Rapid Delivery. In addition, you have embraced Agile Development Methodologies that stress on iterative product development and flexibility to changing environments. There is one major problem in this entire chain, and that is Application Security.
While your product may be rapidly delivered to customers, Application security still remains a massive bottleneck in your continuous delivery pipeline. Application security is critical because companies lose billions of dollars due to vulnerabilities in their applications. Apart from typical vulnerabilities like SQL Injection and Cross Site Scripting, vulnerabilities in authentication, authorization, business logic and cryptographic implementations are more prevalent and can cause massive damage to a software product company.
This is why you need SecDevOps. You need a practical, repeatable and scalable way to deliver Application Security to your product across the Agile and DevOps lifecycle. In this workshop you will receive powerful hands on training on how you can implement scalable and effective security for rapid-release applications. The workshop will be a hardcore hands-on workshop with coverage on the following, but not limited to:
¥ Static Application Security Testing - Integrated with Continuous Integration Services
¥ Rolling out Custom SAST – using Abstract Syntax Trees and Regular Expressions
¥ Customized Security Automation Scripting Framework with Continuous Integration
¥ Creating specialized Application Security Testing Scripts to be integrated with existing Test Suites
¥ Performing Automated, Authenticated and Parameterized Vulnerability Assessments against Web Apps and Web Services by hacking tools like ZAP and w3af
¥ Automation Scripting for Application Security Vulnerability Scanners – OWASP ZAP Custom Scripts – Active Scanning, HTTPSender, Proxy Scripts, with an introduction to Zest Scrits. MITMproxy Inline Scripting
¥ An Introduction to Behavior Driven Security Testing
¥ Parameterized Security Testing for Web Services using the OpenAPI Specification
¥ Security in Configuration management and Continuous Deployment
¥ Security Practices and Considerations for Docker Deployments
¥ Creating Security Configuration Management “Infrastructure as Code” and Validation Scripts – using Ansible
¥ Practical Threat Modeling in an Agile and DevOps world
This full-fledged hands-on training will get the attendees familiar with the various Android as well as iOS application analysis techniques and bypassing the existing security models in both the platforms.
The main objective of this training is to provide a proper guide on how the mobile applications can be attacked and provide an overview of how some of the most important security checks for the applications are applied and get an in-depth understanding of these security checks.
The workshop will also include a CTF challenge designed by the trainer in the end where the attendees will use their skills learnt during the workshop to solve this challenge.
This training will mainly focus on the following :
> Arm basics and Android native code.
> Reverse engineer Dex code for security analysis.
> Jailbreaking/Rooting of the device and also various techniques to detect Jailbreak/Root.
> Runtime analysis of the apps by active debugging.
> Modifying parts of the code, where any part can be specified as some functions, classes and to perform this check or to identify the modification, we will learn how to find and calculate the checksum of the code. Our objective in this section will be to learn, Reverse Engineering an application, get its executable binaries , modify these binaries accordingly, resign the application.
> Runtime modification of code. Objective is to learn how the programs/codes can be changed or modified at runtime. we will learn how to perform introspection or overriding the default behavior of the methods during runtime and then we will learn how to identify if the methods have been changed). For iOS we can make use of tool Cycript, snoop-it etc.
> Hooking an application and learn to perform program/code modification.
> By the end of workshop, based on the course content CTF challenges written by the trainer will be launched, where the attendees will use their skills learnt in the workshop to solve the CTF challenges. The workshop will begin with a quick understanding on the architecture, file system,permissions and security model of both iOS and Android platform.
NOTE:
The tools and techniques used in the workshop are all open source and no special proprietary tools need to be purchased by the attendees for analysis post the training. Some of the tools taught in the training will be helpful in analysis and automating test cases for security testing of the mobile apps:
Drozer
Introspy
Apktool
Dex2jar
Cycript
JD-Gui
SSL Trust killer
Practical DevOps Security and Exploitation is a brand new and unique class by Attify. This class has been created as a result of our many pentest engagement experiences where we have exploited vulnerabilities in the various systems supporting CI/CD during DevOps transition of an organisation. The class covers hands-on techniques to both exploit as well as defend various systems that support the target CI/CD Architecture.
This class takes practitioner's approach in breaking, exploiting and securing systems owned by DevOps teams, thus enabling them to move towards DevSecOps. Some of the topics that we will cover are Exploiting Various tools from the CI/CD landscape like Jenkins, Git, Multiple Cloud instances, practical security issues in Docker instances and setting up your DevSecOps architecture.
This training covers different CI/CD tools with pentesters perspective and hence each tool will be covered as below:
This is an action packed class with over 20+ labs covering a number of attacks, vulnerabilities and exploitation tactics.
Deliverables:
After the training, attendees would be able to:
Minimum Requirements:
Practical Hands-on Internet of Things Hacking is an updated version of our previous year class ran at OWASP AppSec US. We received some great feedback with our class, and decided to take it a step further and redesign the course from the ground up and include tons of new material including medical utilities, smart locks, smart home systems, newer radio protocols, advanced exploitation techniques, new exercises on BLE and lots more
Practical Hands-on Internet of Things Exploitation is the course for you in case you would like to perform real-world pentest on IoT and smart devices. This “new version” of the course takes a practitioner approach, focusing on how to deal with the IoT devices in a real-world scenario, and not just from a research perspective.
Some of the things that we will perform (in an extremely hands-on nature) in this training are:
[+] Attacking IoT devices through hardware and embedded exploitation techniques
[+] Firmware reversing, emulation and binary exploitation
[+] Hands-on labs on serial interfaces - UART, SPI and I2C
[+] JTAG debugging, exploitation and advanced techniques for extracting data
[+] Sniffing BLE, Zigbee and other radio communications
[+] Writing own GNURadio processing blocks to decode radio information
[+] Taking over smart home systems
[+] Remote and Local Exploitation for IoT devices
[+] Attacking a smart home and smart enterprise network
And much more.
Want to learn how to attack an IoT infrastructure or individual devices? You will walk out of the 2-day class having learnt new skills which you could immediately apply in your job/research roles. Come join the course and experience the fast-paced, action-packed IoT Exploitation class.
Note: There is an additional $200 fee for the IoT hacking kit - which includes Attify Badges and custom vulnerable IoT device prepared by us, and an author signed copy of the IoT Hackers Handbook, and additional utilities for other IoT exploitation techniques.
Toreon proposes a 2 day, trainer-led, on-site, Threat Modeling course. The training material and hands-on workshops with real live Use Cases are provided by Toreon. The students will be challenged to perform practical threat modeling in groups of 3 to 4 people covering the different stages of threat modeling on:
• A hotel booking web and mobile application, sharing the same REST backend
• An Internet of Things (IoT) deployment with an on premise gateway and secure update service
• An HR services OAuth scenario for mobile and web applications
This edition also introduces a new section on privacy threats and privacy by design, including a hands-on privacy impact assessment of a face recognition system in an airport. Each student will receive a hard copy of the book: Threat Modeling, designing for security by Adam Shostack (2014, Wiley)
This training is delivered successfully at OWASP Europe 2016 and is selected for OWASP Europe 2017 and Blackhat USA 2017. More details and the outline of the training are available in the attached syllabus.
There is NO charge to attend the Developer Summit, so come join us!
We do ask that you SIGN UP so we have an estimated headcount to be sure we have enough space and food.
Full Day Session
Date: Wednesday, September 20, 2017
Time: 9am-5pm
Room: Coronado N&P
Presenter: Swaroop Yermalkar
Extreme iOS App Exploitation, Defense and ARM Exploitation
Detailed training contents: https://goo.gl/swp7F8 iOS has become one of the most popular mobile operating systems with more than 1.4 million apps available in the iOS App Store. Some security weaknesses in any of these applications or on the system could mean that an attacker can get access to the device and retrieve sensitive information. This training will show you how to conduct a wide range of penetration tests on iOS applications to uncover vulnerabilities and strengthen the system from attacks. Extreme iOS App Exploitation, Defense and ARM Exploitation is a 14 hrs session which will help you conduct end to end pentesting of iOS Applications and will also help you to understand the security measures which needs to be taken. This training will also have CTF challenge where attendees will use their skills learnt in session. To attend this hands-on session, all you have to do is bring your macbook with xcode installed on it.
What will be discussed?
Module 1: Introducing iOS App Security
Module 2: Setting up lab
Module 3: Exploiting iOS Application
Module 4: Exploiting Broken Cryptography
Module 5: Exploiting Key Management
Module 6: Runtime Analysis of iOS Application
Module 7: Reverse Engineering and binary analysis
Module 8: Analyzing iOS Network traffic
Module 9: Exploring iOS Pentest automation frameworks
Module 10: iOS Secure Coding
Module 11: iOS ARM Exploitation
What will attendees learn from attending this presentation?
Items attendees will be required to bring with them
Join our our deep dive discussion on the following OWASP Projects ranging from Incubator to flagship projects. We welcome students and contributors to jump right in and work live with project leaders. Project Reviews will also be conducted throughout the Two Day Session of the Project Summit.
Current OWASP Projects Signed Up:
Presenting on 9/20 @ 9:30 AM - OWASP DefectDojo Project
Presenting on 9/20 @10:00 AM - OWASP ZAP Project & Project Reviews
Presenting on 9/20 @1:00 pm OWASP Core Rule Set Project
Presenting on 9/20 at 2:00 pm OWASP Automated Threats Project
Presenting on 9/20 @ 3:00 pm - OWASP Virtual Village Project Resource
Presenting on 9/20 at 3:45 pm OWASP ESAPI Project
Current OWASP Project Reviews Scheduled:
OWASP Security Knowledge Framework Project
OWASP Security Mobile Testing Guide Project
OWASP Lab/Incubator Projects Deep Dive Health Checks
We would like your feedback and offer a unique opportunity to discuss hot topics.
Currently on the list of topics: (Open to more hot topics)
Resources for Projects
Reimbursement Form & Process
Discourse
Kickstarter Pilot Program
Please use our contact us form with any questions or concerns. Contacts at OWASP Foundation: Matt Tesauro and Claudia Aviles Casanovas will be onsite as well.
“Process” is often seen as a antithetical to the fast-moving nature of startups; security processes, in particular, can be regarded as a direct impediment to shipping cool features. On the other hand, the security of an organization and its users shouldn’t be disregarded for
the sake of speed. Striking a balance between security and nimble development is a vital aspect of a security (in particular, application security) team. At Slack, we have implemented a secure development process which has both accelerated development and allowed us to scale our small team to cover the features of a rapidly growing engineering organization.
In this presentation we will discuss both our Secure Development Lifecycle (SDL) process and tooling, as well as view metrics and provide analysis of how the process has worked thus far. We intend to open-source our tooling as a supplement to this presentation, and offer advice for others wishing to attempt similar implementations. We'll discuss our deployment of a flexible framework for security reviews, including a lightweight self-service assessment tool, a checklist generator, and most importantly a chat-based process that meets people where they are already working. We’ll show how it’s possible to encourage a security mindset among developers, while avoiding an adversarial relationship. By tracking data from multiple sources, we can also view the quantified success of such an approach and show how it can be applied in other organizations.
Fastly offers a content delivery network (CDN) that ubiquitous and high-profile web properties like GitHub, Pinterest, and The New York Times rely on for performance, reliability, and security of their web applications. Fastly edge nodes seamlessly execute customer app security controls, handle sensitive user session data, and act as a trusted man-in-the-middle for TLS traffic. Edge daemons in the Fastly CDN are largely implemented in C. C has many strengths — including flexibility and performance — but C programs are also susceptible to memory corruption bugs that can lead to catastrophic security issues.
Like any successful startup, Fastly has taken many informed risks without things going terribly wrong, building an implicit optimism around legacy codebases and the organization's ability to continually innovate safely on them. Jonathan Foote, senior security architect at Fastly, will discuss the real-world successes and failures that led to an effective strategy for designing and deploying application security hardening measures that balances industry best practices, limited AppSec resources, and startup culture that is conditioned to think about what is going right versus what could go wrong. This talk will describe a minimum-viable approach for implementing application security controls, using deployment of self-service continuous fuzzing of critical internal C codebases including edge HTTP/2 services and Fastly’s varnish-cache fork as a running example.
The myth of attackers breaking through layers of firewalls or decoding encryption with their smartphones makes for great movies, but poor real world examples. In the majority of cases, attackers go for easy targets: web frameworks with security vulnerabilities, out of date systems, administration pages open to the Internet with guessable passwords or security credentials mistakenly leaked in open source code are all popular candidates. The goal of Test Driven Security is to take care of the baseline: apply elementary sets of controls on applications and infrastructures, and test them continuously, directly inside the DevOps deployment pipeline.
A baseline of security controls defines the minimal requirements applications should match before being deployed to production. The controls are simple and specific, such as:
- All websites must implement a Content Security Policy
- Form submission must require CSRF tokens, unless explicitely whitelisted
- SSH Root login must require sudo on all systems
- The rules in firewalls and security groups must be tested at every deployment
- HTTP traffic is prohibited, HTTPS endpoints must use Mozilla's modern guidelines
- Outdated and vulnerable dependencies must be upgraded
The list of security best practices is established by the security team with the help of developers and operators to make sure everyone agrees on their value. A list of baseline requirements can be assembled quickly by collecting those best practices and adding some common sense. The controls themselves are simple and do not require particular expertise, the difficulty comes from testing and implementing them everywhere and all the time.
This is where Test Driven Security comes in. TDS is a similar approach to Test Driven Development (TDD) which recommends developers to write tests that represent the desired behavior first, then write the code that implements the tests. TDS proposes to write security tests first, thus representing the expected state, and then implement the controls that pass the tests.
The TDS approach brings several benefits:
1. Writing tests forces security engineer to clarify and document expectations. Engineers can build products with the full knowledge of the required controls rather than catching up post-implementation.
2. Controls must be small and very specific units which are easy to tests. Vague requirements such as “encrypt network communication” are avoided, instead we will prefer the explicit “enforce HTTPS with ciphers X, Y and Z or all traffic”, which clearly states what is expected.
3. Re-usability of the tests across products is high, as most products and services share the same base infrastructure. Once a set of baseline tests is written, the security team can focus on more complex tasks.
4. Security regressions are caught in real-time, prior to deployment, rather than periodically during manual reviews.
Let’s take an example. A good practice for web applications is to enforce the use of HTTPS on all traffic, which can be done using HTTP Strict Transport Security (HSTS). A website can set a HSTS header returned with HTTP responses to tell web browsers to always HTTPS when connecting to the site, never HTTP. It’s a simple control, trivial to configure at the web server or application level, that we can very easily test for by looking at the headers returned by a website.
The code sample below shows how a simple Bash script can check the value of HSTS on a local application (https://localhost:8080/). This test can easily be part of the integration pipeline, perhaps run automatically as part of a pull request. The test should be defined ahead of implementing HSTS itself. It will fail when the HSTS header is unset or when its value is lower than 90 days. As soon as the website returns an acceptable value, the test will succeed.
#!/usr/bin/env bash
hsts=$(curl -si https://localhost:8080 |
grep 'Strict-Transport-Security:' |
awk '{print $2}' |
cut -d '=' -f 2 | sed 's/\r//')
if [ "$hsts" != "" ] && [ "$hsts" -gt 7776000 ]; then
echo "HSTS test passes. value is $((hsts/86400))days"
exit 0
else
echo "Strict transport security is lower than the expected 90days value"
exit 1
fi
Tests in the TDS approach will fail initially. This is expected to verify their correctness once they pass after the feature is implemented. Security teams should help developers and operators implement controls in their software and infrastructure at first, taking each test one by one and providing guidance on implementation, and eventually transfer ownership of the tests to the DevOps teams. When a test passes, the teams are confident the control is implemented correctly and the test should never fail ever again.
An important part of TDS is to treat security as a feature of the product. This is achieved by implementing controls directly into the code or the systems of the product. Security teams that do not collaborate with developers, and implement security outside of the applications and infrastructure, instigate a culture of distrust that eventually puts organizations at risk. You should shy away from this approach. Not only does it create tensions between teams, it also provides poor security as controls are not aware of the exact behavior of the application and miss things. A security strategy that isn’t owned by the engineering teams will not survive very long, and will slowly degrade over time. It is critical for the security team to define, implement and test, but it is equally critical to delegate ownership of key components to the right people.
TDS adopts the DevOps principles of automating the pipeline and working closely with dev and ops teams. It forces security folks to build and test security controls within the environments adopted by developers and operators, instead of building their own separate security infrastructure.
In the presentation, I will show how we implement TDS using a variety of open source tools:
- OWASP Zaproxy takes care of the baseline scan of web applications. We have worked closely with the core team of ZAP to implement Test Driven Security. We run baseline scan in two ways: 1) In the CI pipeline, like Travis-ci or CircleCI, to give feedback on pull requests and 2) in Jenkins as part of the deployment pipeline of each service, to test staging endpoint every time they are deployed.
- Static analysis tools, like jshint or gas, are used to inspect the source code of applications in CI.
- Dependency management tools, like NSP (Node Security Project) or goreport, are used to check for issues in third party of the applications. We also use closed source platforms like requires.io or greenkeeper.
- Infrastructure auditing is done via tools like Pineapple, which is used to verify the state of security groups in AWS.
Over the past 18 months, we have implemented TDS over a hundred of applications, websites and services and successfully improved our security posture. In this presentation, I will describe the techniques we developed to integrate TDS deep into the DevOps pipeline. The tooling we created will be presented to the audience, with links to resources they can use freely. I will also discuss the human aspect of integrating security processes into development and operations workflows, and how to succeed without disrupting slowing down organization’s SDLC.
Login CSRF is a well-known vulnerability that allows an attacker to hijack a victim’s browser to login to an application using the attacker’s own credentials. This paper applies a similar concept on an application using federated identities. Specifically, we will walkthrough a CSRF issue that can creep into an application that uses OpenID Connect and Oauth 2.0, where more than one identities for a user needs to be linked together. We look at the conditions under which such a Federated Login CSRF may occur and mitigations for the same.
At Netflix Security, we try our best to enable developers by removing roadblocks and providing systems with “sane” defaults that keep everyone from shooting themselves in the foot. When dealing with AWS security groups, not shooting yourself in the foot is important. VPCs, subnets, CIDR ranges, group membership, are all part of the security group vocabulary and essential in ensuring that applications can only talk to each other on an as-needed basis.
How many times have you heard fellow engineers mutter, “Well adding 0.0.0.0/0 seems to work. We will fix it later.” Grouper and Dredge together provide a solution for generating AWS security group rules based on current network data, ensuring that least privilege isn’t a future milestone. Both Grouper and Dredge are deeply integrated into our stack providing developer network insights that were previously unsurfaced. -- unsurfaced is an interesting word choice.
This talk will focus on the history of our security group infrastructure. The challenges of security groups in a large environment (limitations on the number of rules, multiple accounts, lack of cross region security groups, etc.,). Our current security group management and maturity strategy. How Grouper aligns with the freedom and responsibility culture at Netflix.
The Netflix cloud security team has a strong commitment towards open source. Given interest and maturity in these projects, we are open to open-sourcing them in the fu
According to the 2016 Verizon Data Breach Investigation Report, web application attacks are the top source of data breaches today. During the past decade, address space layout randomization (ASLR) has become a feature present in all major OS and a significant guard against buffer overflows and similar attacks by randomizing the location where system executables are loaded into memory.
While ASLR has been effective at the OS level, the principles have not been applied as a means of securing managed virtual machines and runtime environments. Traditional heuristic methods of protection are increasingly ineffective, requiring new approaches to application security. This talk will explore the past, present and future of Java-based application vulnerabilities before sharing a newly developed technology created as a runtime solution to specifically address code injection attacks as a class.
Name Space Layout Randomization (NSLR) is based on the same principle as ASLR, but applied for the first time as an application security feature for the Java runtime. NSLR hardens the Java virtual machine (JVM) by randomizing the JRE namespace (Java packages). Using NSLR inside the JVM, the ownership of bytecode loading is standardized and unvalidated bytecode fails to be executed. In effect, this makes bytecode tampering and a range of code injection exploits so difficult to execute that they become unfeasible, protecting against known and unknown vulnerabilities, including zero-day exploits.
The Problem
Current approaches for protecting against known code injection attacks in applications that run on managed runtime environments involve applying a patch, fixing the vulnerability or disabling the flawed functionality, if possible.
Alternatively, web application firewalls can mitigate some threats, but are often plagued by false positives.
Zero-day attacks are notoriously difficult to protect against since they are, by definition, unknown exploits.
The Solution
We will present a novel approach to dealing with unvalidated bytecode tampering and a range of code injection attacks. With NSLR enabled, JRE packages and classes such as the java.lang.System class are randomized and renamed. Therefore, any exploit that attempts to invoke java.lang.System will fail, because it will not know the new randomized package name. Since NSLR generates a unique package name every time the JVM boots, it is impossible for attackers to guess the new randomized names. Also, it is impossible to access the randomized host package name from the application, since this randomization is not visible to it.
The randomized host package names are transparent to the guest applications and cannot be viewed or accessed from the JRE. In addition, NSLR prevents brute force attacks by using customizable high entropy (96 to 1,024 bits), which would likely require several thousands of years to crack. Finally, NSLR identifies when a code injection attack is attempted, logs the event and throws a ClassNotFoundException that gracefully terminates the attack.
To summarize, NSLR hardens the JVM by randomizing the JRE namespace, which prevents unvalidated bytecode tampering and a range of code injections from executing regardless of the attack vector and the vulnerability (known or zero-day) that is being exploited.
This approach provides absolute protection against both known and unknown code injection vulnerabilities with zero false positives, and does not require any changes to the application code.
Attendee Takeaways
Unvalidated bytecode tampering and injection in the JVM is a type of code injection attack that was never addressed properly. Code injection attacks rank 6th among 2055 known vulnerabilities according to MITRE.
Currently, the most common approach to protecting against them is to identify and fix/patch those vulnerabilities. This is not ideal, and may or may not be feasible. A firewall, IPS or WAF can be used to try to mitigate code injection attacks, but they are often plagued by false positives. More importantly, all the mainstream JVMs lack the appropriate mechanisms to identify and protect against these types of code injection attacks.
Attendees will leave this presentation with a working knowledge of how the next generation of application security solutions will be used against code injections. In the future, web-based applications will be protected by highly accurate, easy to operate virtualized technology in the runtime.
Attendees will gain:
1. Exposure to recent advances in runtime protection in the application security space
2. Understanding of the most frequently employed unvalidated bytecode attacks in the JVM, where they occur and forms of mitigation
3. Working knowledge of the new, state-of-the-art application security technique neutralizing code injection attacks
4. Unique insight into how these types of solutions are designed and developed from the software architect himself
As companies make the cultural shift towards DevOps, native mobile applications present a number of unique challenges. Results of a recent survey suggest that 81 percent of enterprises and 70 percent of small-to-medium businesses have adopted some form of DevOps. Yet another survey, though, reports that only 29 percent of mobile applications are undergoing security assessments. Why does this gap exist? I will examine the unique DevOps problems put forth by mobile app development, and discuss how implementing mobile DevSecOps practices can mitigate their effects.
The talk will focus on identifying and demonstrating the impact of mobile-specific DevSecOps challenges:
Broader mobile framework specialties: Examining a mobile app extends beyond the application code itself. A fully functional mobile security team must be able to forensically analyze data stored on the phone, examine APIs and communications protocols, perform server-side penetration testing, and reverse engineer an application to perform thorough assessments at scale.
Technology fragmentation: Not only are mobile apps deployed across a multitude of hardware devices, steps taken by Apple and Google to secure the iOS and Android platforms eliminate avenues security pros use to detect and respond to mobile security threats.
Mobile apps expose enterprise architecture: A mobile app is often an endpoint for a much deeper enterprise architecture, so a compromised app can have far reaching effects.
Faster time frames: Even in the fast paced DevOps world, mobile applications have even more accelerated timelines for release. In order to build - and maintain - a user base, mobile apps need to be deployed and updated more frequently. This shorter development cycle stresses systems that may already be in place.
Push vs. pull updating - the unique nature of app stores mean that users have to “pull” updates, rather than the developer “pushing” them to existing installations.
The talk will then focus on how to leverage the strengths of DevSecOps processes to mitigate each these challenges in mobile. I will discuss strategies connected to each of the problems above with a focus on leveraging automation, process, and culture. A particular focus will be making the case for early and automatic security testing and providing examples of practical solutions.
I have worked on enterprise APIs being used by millions of users worldwide both as a Enterprise Security Architect and as a developer building these services. In this session, I will talk about Top 10 ways to design and build secure Microservices to protect your users and your reputation. This top 10 list includes:
1. Use the latest version of TLS
2. Designing a secure Infrastructure and Network whether on prem or in cloud
3. Best Practices in Authentication to authentication your clients or end users.
4. Authorization of your end users or clients so they get just the right access based on least privilege and need to know.
5. Protecting your APIs against Distributed Denial of Service by using patterns such as Rate Limiting, Throttling, Daily limits etc.
6. Alerting and Monitoring your APIs to detect abnormal patterns and security issues.
7. API resiliency that directly affects Availability of your Microservices.
8. Encrypting & Hashing sensitive data - at rest and/or in transit - in memory, in cache and in db, in transit, in UI
9. Key management security
10. Session Management best practices
Here’s a story: you have built the ultimate AppSec program for your organization, and you complete the vital step of scanning your code for vulnerabilities along the development process. Your policy was very clear and strict about high priority vulnerabilities while lower vulnerabilities are addressed when time permits. Having achieved a significant coverage, you’re left with only three medium-severity vulnerabilities. You are about to sign off on the release; what could go wrong?
Watch as a downloaded app is attacked through a live demo, and learn the real dangers of three of the most commonly found (and ignored) medium level vulnerabilities.
Join this session to
• Watch how, when leveraged properly, medium level vulnerabilities become serious attacks
• Understand why static source code analysis is vital to locate vulnerabilities that your pen tests are likely to miss
• Learn how to use static application security testing as an attack technique
Writing secure code is not as glamorous as releasing the next cool feature. However, we know that fixing security vulnerabilities in production is hard and costly. In order to have a more secure application it is important to consider what makes an application secure from the start during the design phase. But what security requirements make sense? How can a security organization track whether the multitude of applications are adhering to application security best practices and known secure states? How does a development team prioritize all the security requirements?
Driving uniformed security requirements across a large company can be no small task. Many development groups write security requirements guided by regulation or industry standards for their specific application that are not seen by other development teams or the security organization. Further difficulties arise from teams that are dispersed using different tools and processes. Acquired development organizations that are accustomed to different processes pose their own challenges. The sum of these items leads to a siloed approach to writing and tracing security requirements complicating efforts by the security organization to understand how applications are developing secure code.
With the OWASP ASVS, a set of verification statements can be used to create a list of functional and non-functional requirements and controls that an application can adhere to in order to maintain a secure posture for their risk tolerance. Our Application Security team used the verification statements from the ASVS and created a set of security requirements, controls, and technical design decisions that our applications can use in their normal Scrum process as they would for feature development. The Application Security team also provides a priority ranking on each of the work items in order to assist the application in prioritizing the work.
Our team developed a modified version of the open source Google VSAQ in order to present our applications with a questionnaire that determines the ASVS level that an application should strive toward. This questionnaire will ask questions related to the type of features and functions that the application may have in order to identify the tasks that the application needs to complete to meet that ASVS level. In some cases, the application may use a third party or another internal application to handle the functionality that is listed in the ASVS giving the development team the ability to opt out of some security requirements. For instance, the user authentication may be a module developed by another application as in the case of an SSO enabled application.
As with most projects, creating new processes and procedures for something specific like security requirements can create turmoil and outright revolt among the consumers of the new process. So bringing a set of uniformed security requirements to an established organization requires working within the existing process. To this end we are utilizing current internal requirements tracking, enhancement tracking and testing tools as a way to reduce reluctance to the new project. Through this already defined process security tasks can be viewed and treated as any other type of development tasks. This allows the security organization to see which applications are adhering to the controls, which ones are not, which controls are the most challenging across the application base, and follow the work through the lifecycle using standard reporting.
Test plans can be written using the ASVS verification statements as they are or as a guide to a more specific test plan. To verify that the requirements have been met by an application, the test plans will be mapped to the requirement in a requirements tracking tool.
Secure development does not need to be painful or difficult. In this talk I would like to show how an organization can apply the ASVS to their Software Security Life Cycle to create more secure applications. Working with a ready baked set of security requirements and methods of validation takes the ambiguity out of creating security requirements and makes them more consumable to development teams. The OWASP ASVS provides the guidance to that prepared set of requirements that can be used in an already established software development life cycle.
This talk will introduce a new approach to SDL. At Twilio we call it End to End Security Engineering. It’s End-to-End because it covers the full product lifecycle, from Security Design to Monitoring and gives the ability to measure the state of security at each point.
The approach defines a ‘perfect secure system’ and produces metrics which tell us where we are relative to that perfect system.
The final state of the product’s security and risk depends on ‘collective understanding’ of threats and attacks as well as investments in building controls, tests and detections. Then we measure and adjust them to improve their effectiveness.
A perfect secure system is one for which:
- All products and features are threat modeled
- All possible attacks are identified
- All attacks are being monitored for
- All attacks are protected with controls
- All controls are covered with tests which check validity of implementation
- All controls are shown to be effective
To measure this we keep track of the following metrics:
- % of threat modeled products/features
- experience of threat modelers
- % of attacks being monitored
- % of attacks with implemented controls
- % of controls covered by full tests
- # of successful attacks
- # of prevented attacks after control has been put in place
Leveraging Blockchain for Identity and Authentication in IoT is good for Security
Since the beginning of the internet, attempts have been made to solve the problem of privacy and security. Every effort has had challenges of inconvenience, cost and insecurity.
How do we prove our identity?
Blockchain technology and its mutual distributed ledgers (MDL) cannot be altered and allow people and companies to record, validate and track transactions throughout a network of decentralized computer systems. These MDLs are databases with a time stamped audit trail.
By leveraging this technology, an app on our device will hash our identifying information and insert this into the public Blockchain. Anytime you need to authenticate to another service or user, you share the information which is then sent through the algorithm and checked against the Blockchain. Once authenticated, your information for identification is not needed again.
If the hashed information is decentralized and provides interoperability. Personal information never leaves the device and is not stored on a centralized server. Taking the personal data, hashing it and then discarding everything but the hashes of our personal data allows the network to accept the information in the same manner as our ID cards.
These Blockchains open the door to innovation and enables more interoperability connecting various distributed services.
There can be 2 unique MDLs; one to hold the encrypted documents and a separate ledger that will hold encryption key access which are folders encompassing our identity, health or other qualifying records. Driver’s license bureaus can provide us a digitally signed copy of our driver’s license that we control. We then offer controlled usage to entities that need to inspect the documents, the information recorded on the MDL.
This use of immutable ledger can become the accepted modality of the future.
OWASP iGoat is an open source self-learning tool for iOS developers, mobile app pentesters. The best thing about iGoat is that it follows client-server architecture and supports all iDevices including iPad, iPhone, iPod and Macbook simulator for iOS 8/9/10. It was inspired by the WebGoat project, and has a similar conceptual flow to it.
As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson.
The lessons are laid out in the following steps:
Brief introduction to the problem.
Verify the problem by exploiting it.
Brief description of available remediations to the problem.
Fix the problem by correcting and rebuilding the iGoat program.
This talk is all about how iOS developers, security analysts can dive deep into iOS App Security using iGoat tool. This talk will start from setting up iGoat to exploiting latest exploits in iOS app. I’ll also release a new version of iGoat with tons of new exercises at Appsecusa 2017.
Description:
The Home Depot, the world’s largest home improvement retailer, has been providing hammers, saws, nails, lumber, and paint to Do-It-Yourselfers and Pros alike since 1978. In the same spirit, the Product Security team offers self-service tools and materials to help software developers analyze their source code and deployed applications at scale and speed, matching the pace of agile.
Key Takeaways:
• Build tooling using the same technologies and methods developers use
• Ensure tooling is available when and how developers want it
• Eliminate friction by providing meaningful results and teaching developers how to interpret them
• Empower developers to determine a path toward issue resolution
We will map the GDPR requirements to the typical software security activities as part of a Secure Development Lifecycle. This will cover:
• How to include the DPO as part of the software security governance?
• Providing privacy awareness training to developers
• Including privacy in secure coding guidelines
• Including a Privacy Impact Analysis as part of software risk analysis.
• Mapping the GDPR to software security requirements
• Applying privacy by design on software architecture
• Including privacy threats in software threat modeling
• Including a privacy security checklist as part of software security testing
• Applying GDPR specific breach notification requirements on the vulnerability and incident management processes
The talk will focus on practical implementation aspects and demonstrations of real life use cases encountered in our software security and privacy projects.
More details can be provided in a detailed submission.
As security professionals charged with protecting large enterprise application portfolios, we continually find ourselves managing a wide array of disparate security initiatives, each of which demands to be treated as a top priority. Few of these initiatives ever achieve full coverage across the application portfolio. So we’re left to prioritize on the fly and try to keep everything we’re juggling in the air. Inevitably some will get dropped.
What if we could develop an AppSec program that ties those disparate initiatives together into a repeatable and continuous program that not only addresses coverage of the entire portfolio but acts as an enabler of high-paced development paradigms such as DevOps and CI/CD? In this presentation we’ll discuss a model for deploying AppSec programs that addresses these goals. A strategy for tying together various security activities including threat modeling, code reviews, and penetration tests, with business and risk processes in a way that actually makes development more efficient. We’ll discuss how an organization can tailor their own program based on the model but addressing the unique challenges and business goals of the individual firm.
You’ll see how the Continuous AppSec Model leverages the key principles of the latest OWASP SAMM to break down and unify your security activities. You’ll learn how an Application Security Program can be designed to enable continuous improvement within the program itself. You’ll discover how this continuous improvement allows for implementation of a program based on this model in an easily digestible and incremental fashion. You’ll understand how a truly continuous program allows you to better prioritize your security initiatives by providing you a clearer picture of the risks across your environment. You’ll leave with a better strategy for enabling your application teams to not only support but actually advocate for the security practices already employed within your enterprise as well as those perhaps thought too advanced for your organization.
The OWASP 2017 top ten is adding a new category of underprotected APIs. This reflects how RESTful Web APIs are rapidly becoming the backbone of communication on the modern web. A whole series of new challenges are thus presented for dealing with security and access authorization issues. These are not well covered by existing tools or techniques. This talk will cover some of the potential threats that result from failure to secure Web APIs sufficiently and discuss some of the emerging security technologies in the field. In this API driven world there are a more complex set of API consuming clients, some of which may need to embed access credentials such as API keys. We will discuss the differences between software authorization via static API keys and user authorization via OAuth2 and the interplay between them. We will pay particular attention to API consumers such a mobile apps where the code must be published in the public domain. We will look at the typically poor level of practice in concealment of access credentials such as API keys in these apps. Some practical advice with code examples will be provided about how to improve the security posture of mobile apps accessing an API. We will cover the use of TLS and how it is not an effective countermeasure to credentials being extracted unless certificate pinning is also used to prevent Man-in-the-Middle attacks against the app. There will be some practical advice on how to implement TLS pinning with code examples. Finally we will look at more advanced techniques such as app hardening, white box cryptography and software attestation for mobile applications where security is crucial. Attendees should gain a good understanding of the underprotected API problem, some short term practical tips to improve their API security posture with minimal effort and an appreciation of emerging tools and technologies that enable a significant step change in security.
The information security industry has a long history of challenges when it comes to ensuring the safety of user input data. User input must be escaped when using a template to build a string. Whether in HTML, SQL, or shell commands it is best practice to escape data from untrusted sources. Most of the time this is done by having the developer think through all possible code paths the string could have taken. This requires heroic effort and is still error-prone. Far more reliable is using a type or metadata system to tag the data and track it through the system, but this requires the designer of the system to consistently use the tagged string types, or have some additional runtime support to provide a tracking mechanism. Further, such techniques (explored extensively in academic research) have invariably encountered severe performance impacts, making them unpractical for runtime protection.
We propose a black-box taint tracking system in which we observe only the user inputs (http parameters) and system outputs (commands and SQL queries). By parsing the input and the output commands we can determine if an input data partition straddles an output data partition. This would indicate that the input data partition had injected information from the data portion of the input to the command portion of the output. Since we look only at the input and output of the application code, code complexity is arbitrary. Previously, if a system was not designed from the beginning to have taint tracking, introducing taint tracking was cost prohibitive. “Approximate taint tracking” allows after-the-fact introduction of these protections in a way that is cost-effective, and performant.
Getting developers to care about security is tough, but turning your developer training into a hands-on puzzle game with a Capture the Flag (CTF) event can create excitement while effectively accomplishing the real goal of the training. Permanently open their eyes to what goes wrong when security controls are left out and give them the attacker’s perspective to look critically at their code moving forward. Consider that students remember 20% of what they hear – and 90% of what they do. Hands-on training is radically more effective.
This presentation will discuss the pedagogical underpinnings to the technique (so management will approve it), and practical recommendations on implementing an event (so that the participants will have a good time). After several years of running events in a variety of contexts, I’ll share some success stories and admit to some failures that will help put you on the right path for your own event.
Topics will include:
• Designing your event infrastructure to minimize risk and satisfy IT policies.
• Preparing difficult, but solvable challenges.
• Managing players while encouraging them to break the rules.
Although Web Application Firewalls (WAFs) are recognized as an effective aspect of a defense in depth strategy, there are few tools that attempt to objectively review their effectiveness. Research companies like NSS or Gartner perform benchmarks of WAFs, but their methodologies are rarely disclosed. With the advent of site reliability and devops cultures, infrastructure as code has been a strategy to verify functionality of products. This talk brings that same mentality to WAFs; not only do we verify WAF functionality within deployments, but we also provide a method to verify WAF defenses against new exploits and attacks. We do this with our project FTW - Framework for Testing WAFs.
We achieved two outcomes from this project. The first was to design a framework that is extendable to test arbitrary WAF implementations. This would allow engineers to compare WAFs to help them make an informed purchase decision for their organization instead of relying on reports and literature that do not disclose their testing methodologies. Secondly, we want to have the ability to develop new tests without the need for development experience. This allows rapid prototyping of attack payloads without the need of a scripting language. These payloads are then executed against various WAF implementations to see how the WAF responds. Once tested, new rules can be deployed within the WAF and then the attack is added to a corpus of attacks for continuous testing.
We will first review the design of the tests. We use the OWASP Core Ruleset Version 3 (CRSv3) as our benchmark for web attacks and defenses, so the first task was to translate the CRS and write attacks to make sure the rules trigger. This resulted in a corpus of 1000s of attacks provided for end users at no cost. Tests are written in YAML format, and we will go into detail on how the format is developed to include both basic HTTP attacks as well as more advanced multi-stage attacks.
Next, we will review the architecture of the code. Py.test is used as the testing foundation due to the wide adoption within industry it enjoys, its ability to parametrize the YAML test files, as well as its ease of use in continuous integration environments. We show how an individual can set up an FTW testing environment and start writing or editing tests, as well as creating new ones. We will then show continuous integration strategies to test and deploy new WAF rules. We use Travis-CI as the continuous integration technology, but traditional CI or deployment tech can also be used.
We then will move into the crux of our presentation where we highlight the results. We plan to discuss how this project is being used throughout the community. The ModSecurity team used FTW extensively for regression testing in the CRS. We will show lessons learned and how regression testing in security is extremely important. We will also show a use case for how an origination uses FTW to ship WAF rules for their customers on the edge. Strategies to ship WAF rules include continuous integration and applying security to the SDLC of these deployments. Lastly, we highlight a journaling feature that allows security engineers and red teamers issue a battering ram of web attacks and log responses into a local database for pentest reports.
The Current Code
https://github.com/crs-support/ftw to check our code
https://github.com/fastly/waf_testbed for a VM that spawns the latest CRS w/ the latest FTW to start running tests
https://github.com/SpiderLabs/OWASP-CRS-regressions/tree/master/tests for CRS attacks
https://github.com/SpiderLabs/owasp-modsecurity-crs/ latest CRS
Each Android app runs in its own VM, with every VM allocated a limited heap size for creating new objects. Neither the app nor the OS differentiates between regular objects and objects that contain security sensitive information like user authentication credentials, authorization tokens, en/decryption keys, PINs, etc. These critical objects like any other object are kept around in the heap until the OS hits a memory constraint and realizes that it needs more memory. The OS then chooses to invoke garbage collector in order to reclaim memory from the apps. Java does not provide explicit APIs to reclaim memory occupied by objects. This leaves a window of time where the security critical objects live in the memory and wait to be garbage collected. During this window a compromise of the app can allow an attacker to read the credentials. This is a needless risk every Android application lives with today. To exacerbate the situation, apps today heavily make use of Identity providers to implement Open ID/OAuth based authentication and authorization.
In this paper we propose a novel approach to determine at every program statement, which security critical objects will not be used by the app in the future. An Android application once compiled, has all the information needed to determine this. Using results from our data flow analysis [1] we can decide to flush out the security sensitive information from the objects immediately after their last use, thereby preventing an attacker who has compromised the app from reading security critical information. This way an app can truly provide defence in depth, protecting sensitive data even after a compromise.
We propose a new tool called Androsia, which uses static program analysis techniques to perform a summary based [2] interprocedural data flow analysis to determine the points in the program where security sensitive objects are last used (so that their content can be cleared). Androsia then performs bytecode transformation of the app to flush out the secrets resetting the objects to their default values. The data-flow analysis associates two elements with each statement in the unit control flow graph called flow sets: one in-set and one out-set. These sets are (1) initialized, then (2) propagated through the unit graph along statement nodes until (3) a fixed point is reached.
We leverage the power of Soot [3], a static Java-bytecode analysis framework, to identify the points in the program where an object is last used (LUP). The detection of Last Usage Point (LUP) of objects, requires analysis of methods in a reverse topological order of their actual execution order; which means that the callee method will be analyzed before the caller method. We construct flow functions for the analysis and use them to propagate the data flow sets [4]. The flow functions are as follows:
Out(i) = φ if S(i) is exit node in CFG
= ∪ {In(j)} | where S(j) is the set of all successor statements of S(i) | otherwise
In(i) = Out(i) ∪ Gen(i); where
Gen(i) = {var(y)} | if S(i) is of the form: x = y
= {var(y)} | if S(i) is of the form: x = if(y)
= {var(y)} | if S(i) is of the form: x = while(y)
= {p(i)} | if S(i) is of the form: x = f(p)
= {φ} | otherwise
(In the interest of space: pls. refer [1] to know more about how the flow functions work in a data flow analysis)
In our analysis, the flow sets are propagated backwards in the Unit graph [5]. The analysis result corresponding to a method is kept as a summary for that method and is propagated to caller methods at the method call site. Hence giving rise to an inter-procedural summary based analysis.
Using the results from this analysis we then perform bytecode transformation on the target app to remove sensitive information from the objects at the identified program points from our analysis. As a case-study, we take Android apps and manifest the security that Androsia has to offer.
[1] Data flow analysis, https://en.wikipedia.org/wiki/Data-flow_analysis
[2] D. Yan, G. Xu, and A. Rountev. Rethinking soot for summary-based wholeprogram analysis. In Proceedings of the ACM SIGPLAN International Workshop on State of the Art in Java Program Analysis, SOAP ’12, pages 9–14, New York, NY, USA, 2012. ACM
[3] Soot: a Java Optimization Framework. http://www.sable.mcgill.ca/soot/
[4] Implementing an intra procedural data flow analysis in Soot. https://github.com/Sable/soot/wiki/Implementing-an-intra-procedural-data-flow-analysis-in-Soot
[5] UnitGraph. https://www.sable.mcgill.ca/soot/doc/soot/toolkits/graph/UnitGraph.html
2017 WASPY Awards
Each year there are many individuals who do amazing work, dedicating countless hours to share, improve, and strengthen the OWASP mission. Some of these individuals are well known to the community while others are not.
The purpose of these awards is to bring recognition to those who "FLY UNDER THE RADAR". These are the individuals who are passionate about OWASP, who contribute hours of their own free time to the organization to help improve the cyber-security world, yet seem to go unrecognized.
HTTP/2 is the second major version of the HTTP protocol. It changes the way HTTP is transferred “on the wire” by introducing a full binary protocol that is made up of TCP connections, streams, and frames, rather than a plain-text protocol. Such a fundamental change from HTTP/1.x to HTTP/2, means that client-side and server-side implementations have to incorporate completely new code in order to support new HTTP/2 features. This introduces nuances in protocol implementations, which, in return, might be used to passively fingerprint web clients.
Our research is based on more than 10 million HTTP/2 connections from which we extracted fingerprints for over 40,000 unique user agents across hundreds of implementations.
In the presentation, I intend provide the following:
• HTTP/2 Overview
- Introduction into the basic elements of the protocol
- a review the different components chosen for the fingerprint format (alongside a discussion on those left out)
- Potential use cases of the proposed fingerprint
- Usage Statistics - prevalence of HTTP/2 usage on Akamai’s platform
• Examples of common HTTP/2 Implementations & Client fingerprints collected during the research
• HTTP/2 support (or the lack of) among common web security tools (Burp suite, sqlmap, etc.)
• Review of attacks over HTTP/2 observed on Akamai’s platform
References:
http://akamai.me/2qWIqON - whitepaper published by Akamai’s Threat-Research Team.
Cookies are an integral part of any web application and secure management of cookies is essential to web security. However, during my years as a security consultant I've often encountered various myths and misconceptions regarding cookie security from both developers as well as other security professionals. This talk will dive into the details of cookie security and highlight some of the lesser known facts about well-known cookie attributes. For example, we will see why the ‘Secure’ attribute doesn’t make a cookie immune against active man-in-the-middle attacks, how JavaScript can manipulate cookies marked with ‘HttpOnly’, why setting the ‘Domain’ attribute to the origin host may make it less secure and how other applications on the same host still can access cookies scoped to a path outside their application. This talk will also cover many of the recent improvements to cookie security implemented in modern browsers, such as ‘Strict secure cookie’, ‘Cookie prefixes’, and the ‘SameSite’ attribute. This talk will give you a solid understanding of the pitfalls affecting cookie security, the risks associated with these, and how you can leverage modern security specifications to enhance the protection of cookies in your web application.
Tentative outline (subject to change):
-Cookie Basics
-Cookie Lifetime
o Persistent vs. non-persistent cookies
o Expires and Max-Age Attribute
o Security implications
-Cookie Scope vs. Same-origin Policy
-Secure Attribute
o What it protects against
o What it doesn’t protect against
o Targeting ‘Secure’ cookies in MiTM attacks
o Demo
-HttpOnly Attribute
o What it protects against
o What it doesn’t protect against
o Attacking ‘HttpOnly’ cookies from JavaScript
o Demo
-Path Attribute
o Isolating cookies between applications on same domain
o Compromising cookies scoped to another application’s path
o Demo
-Domain Attribute
o Broadly scoped domains
o Narrowly scoped domains
o Risks with setting the domain attribute
-Modern Cookie Protections
o SameSite Attribute
o Cookie Prefixes
o Strict Secure Cookie
-Summary
o Is there an ultimate cookie configuration?
Our goal was to fix as many high-risk vulnerabilities throughout the GitHub Open Source project portfolio as we could with a minimum of effort. The intent was to simulate portfolio wide remediation in a large and diverse organization within a context that allows sharing concrete statistics and experiences.
Fixing XSS throughout a portfolio of applications is more challenging than fixing a single application. In addition to the remediation work required for a single application, fixing a portfolio requires getting developer buy in, complying with various coding style guides, integration with each project’s existing processes, testing, metrics, and more.
This presentation will discuss how we did it, lessons learned, as well as some alternatives. Three things that made our scaling approach unusual was:
1) Focusing on risk broadly across application portfolios instead of a single application.
2) Focusing on adding missing security controls instead of the exploitability of vulnerabilities.
3) Automating JSP source code modification
We will compare the approach that we used on this project to more traditional manual and automated techniques that focus on vulnerability detection, as well as scaling through training, and scaling through building offshore capabilities.
Most businesses have at least one old clunker app kicking around, and the longer it has been around and more clunky it is, the more likely it is to be vital to your business (otherwise you’d have gotten rid of it, right?). So how do you approach getting an old clunker migrated to the cloud? Think you can put it off? You’ll probably discover that there is a compelling business reason to get it migrated lurking just around the corner that will force your hand. Whether it is as mundane as a data center consolidation effort, of as aspirational as a push to transform the business to be more agile and customer focused, the cloud has your app in its sights and will not rest until your app has made the leap.
There are a variety of approaches touted for app migration, from decomposition into micro-services, to blatant lift-and-shift, so how can you tell which migration pattern is most likely to succeed and meet business objectives? Much like approaching a renovation of an old house, how can you tell which apps are the ‘scrapers’ where refactoring might as well mean rewriting, and which ones ‘have good bones’ and might successfully make the transition without much more than basic updates? Cloud purists will promote a refactoring pattern where an apps decomposed into a collection of cloud-native micro-services. Others will promise that you can forklift the app into a cloud with almost no change. But do you understand the benefits and pitfalls of the various approaches? Is there a middle path?
Many questions arise, such as: Should the app be migrated to a public or private cloud? Would an IaaS or PaaS be a better fit? Can it be outsourced to a SaaS, essentially replacing the app with a cloud native offering and avoiding migration of the app itself? What are the security implications of each app migration pattern combined with the target cloud environment? Does my legacy app have inherent design assumptions that conflict with the design assumptions of the target cloud environment? Are there the necessary supporting organizational capabilities (DevOps, Agile, DevSecOps, Test Driven Design, etc.), and technologies (continuous integration/continuous deployment, configuration management automation, etc.) to support cloud migration success?
This presentation will explore these topics and more to provide a roadmap to making both good security decisions and good decisions overall in planning your app’s migration to the cloud.
What if you could turbocharge your web hacking without having to sacrifice efficiency? Since pure automation misses so much important information, why not use powerful alerts created from real threat intelligence? What if you had these powerful alerts in as a plugin in a tool that that is so ubiquitous in web hacking that it’s synonymous to its very definition? What if this plugin not only told wyou where to look for vulnerabilities, but also gave you curated resources for additional exploitation and methodology? What if you could organize your web hacking methodology inside of your tool? Well, dream no more! HUNT is a new Burp Suite extension that aims to arm web hackers with parameter level suggestions on where to look for certain classes of vulnerabilities such as SQL Injection, Command Injection, Local/Remote File Inclusion, and more! The data that drives this plugin are parsed from hundreds of real-world assessments which provide the user with the means to effectively root out critical issues. Not only will HUNT help you assess large, hard targets more thoroughly, but it also aims to organize common web hacking methodologies right inside of Burp Suite. As an open source project, we will go over the data driven design of HUNT and its core functionality.
Detailed Outline
HUNT's core idea is to parse large data sets of web application flaws and transforming the results into a meaningful testing tool. We've taken one of the largest known vulnerability data sets, the bounty data at Bugcrowd, and scrubbed it all down to vulnerability class and parameter name. With this data, we can infer patterns in web application vulnerability locations.
Today, one of the things we struggle with as an industry is manual testing for large, complex applications. With the amount of surface area to cover on assessments, we are forced to rely on automation. And while automation is great, it fails to apply the years of experience we have as pentesters in identifying edge-cases in web vulnerabilities that cannot be easily found by anything other than a human.
HUNT will log and alert commonly vulnerable areas for manual testers to look at based on the collective knowledge of hackers all over the world. This will help break down complex applications into meaningful and testable areas. We are not aiming to replace scanners in this fashion, but instead, we are making sure web hacking gets the manual tester love that it truly deserves.
The tool covers critical vulnerability classes that can be meaningfully parsed at the moment:
SQL Injection
Local/Remote File Includes
Directory Traversal
OS Command Injection
Server Side Request Forgery
File Upload Vulnerabilities
Insecure Direct Object References
Server Side Template Injection
Sections of the Talk
The Problem
Web hacking training lacks detailed tribal knowledge of vulnerability location
Sites are larger and more complex than ever and even harder to test thoroughly with current manual testing techniques and methodologies
No in-tool workflow for web hacking methodologies
The Data
Understanding the data set
Learning about data and patterns discerned
Give examples of the data of vulnerable parameters
Examples: file, document, folder, style, pdf
The Tool
Explore HUNT's install and GUI
Explore some sample alerts live
Explore HUNT's methodology and tester references
Explore HUNT's methodology organization tab
Talk about the future and contribution
In 1984, Ken Thompson wrote, “You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)” [1] Yet modern software applications are 80% open source components.[2] The supply chain is total anarchy.
All this third-party code runs with the full privileges of the application, essentially granting full access to host, backend, datacenter, and possibly intranet. Obviously, if a popular component, like Log4j or Apache Commons, were trojaned, it would give an attacker a hall pass to most of the datacenters in the world. Much of our trust in open source components comes from the fact that the source is public and “given enough eyeballs, all bugs are shallow.” [3] Unfortunately, in the Java ecosystem (and most other environments), there is literally no assurance that a given binary matches the source.
This talk reports on the results of a large-scale experiment to search the universe of Java libraries for malicious discrepancies between source code and binaries. We created an automated security pipeline that automatically matches repositories, builds code, performs a “security diff” of the bytecode instructions, and generates human-readable reports for analysis. Our “security diff” tool ignores inconsequential differences between compilers, flags, and versions, so that only truly different code gets flagged. The experiment is currently underway and hundreds of libraries have been analyzed.
Of course, source-to-binary traceability is not everything, a malicious developer could hide attacks in the source code [4]. A crafty malicious developer would intentionally introduce vulnerabilities that look like accidents to establish some plausible deniability. So, given the trust that these libraries have been granted, and the potential attractiveness to an attacker (particularly nation-sponsored or financially motivated hackers), we absolutely have to know if public source code matches the binaries we blindly trust.
This session will cover a real-word approach to an enterprise wide, multi-factor authentication deployment at a fortune 500 financial services company with 30,000+ workforce. We’ll discuss the technical challenges we faced in adapting modern passwordless authentication protocols such as SAML and Kerberos to a wide range of client computing devices and legacy technologies. We’ll also discuss the critical user experience decisions and lessons learned during the implementation to enable workforce authentication any time, any place, and any device.
Machine Learning (ML) has found it particularly useful in malware detection. However, as the malware evolves very fast, the stability of the feature extracted from malware serves as a critical issue in malware detection. The recent success of deep learning in image recognition, natural language processing, and machine translation indicates a potential solution for stabilizing the malware detection effectiveness. We present a color-inspired convolutional neural network-based Android malware detection, R2-D2, which can detect malware without extracting pre-selected features (e.g., the control-flow of op-code, classes, methods of functions and the timing they are invoked etc.) from Android apps. In particular, we develop a color representation for translating Android apps into rgb color code and transform them to a fixed-sized encoded image. After that, the encoded image is fed to convolutional neural network for automatic feature extraction and learning, reducing the expert’s intervention.We have run our system over 800k malware samples and 800k benign samples through our back-end (60 million monthly active users and 10k new malware samples per day), showing that R2-D2 can effectively detect the malware. Furthermore, we will keep our research results on http://R2D2.TWMAN.ORG if there any update.
2016 was the year of Java deserialization apocalypse. Although Java Deserialization attacks were known for years, the publication of the Apache Commons Collection Remote Code Execution (RCE from now on) gadget finally brought this forgotten vulnerability to the spotlight and motivated the community to start finding and fixing these issues.
One of the most suggested solutions for avoiding Java deserialization issues was to move away from Java Deserialization altogether and use safer formats such as JSON. In this talk, we will analyze the most popular JSON parsers in both .NET and Java for potential RCE vectors.
We will demonstrate that RCE is also possible in these libraries and present details about the ones that are vulnerable to RCE by default. We will also discuss common configurations that make other libraries vulnerable.
In addition to focusing on JSON format, we will generalize the attack techniques to other serialization formats. In particular, we will pay close attention to several serialization formats in .NET. These formats have also been known to be vulnerable since 2012 but the lack of known RCE gadgets led some software vendors to not take this issue seriously. We hope this talk will change this. With the intention of bringing the due attention to this vulnerability class in .NET, we will review the known vulnerable formats, present other formats which we found to be vulnerable as well and conclude presenting several gadgets from system libraries that may be used to achieve RCE in a stable way: no memory corruption -- just simple process invocation.
Finally, we will provide recommendations on how to determine if your code is vulnerable, provide remediation advice, and discuss alternative approaches.
The bigger the company you're working in, the more technologies and methodologies used by development teams you are going to face. At the same time, you want to address security risks in an appropriate, reliable and traceable way for all of them.
After a short introduction of a unified process for handling security requirements in a large company, the main part of the talk is going to focus on a tool called SecurityRAT which we developed in order to support and accelerate this process.
The goal of the tool is first to provide a list of relevant security requirements according to properties of the developed software (e.g. type of software, criticality), and afterwards to handle these in a mostly automated way - integration with an issue tracker being used as a core feature.
Work in progress (currently targeting mainly integration to other systems, automated testing of requirements and reporting) as well as future plans will form the last part of the talk.
Part One: The Problem
The current solutions of sensor based perimeter defense have their limitations. Taking home defense as an example, sensors are located at all possible breach points of the perimeter (windows, doors, etc). The alarm is triggered only when there is an actual perimeter breach. It takes time for the alarm company to report to local police and more time for police to send patrol cars. If the attackers are determined to finish the task quickly and take off before police can arrive, the chance of getting away is very high.
There is one important additional weakness: this traditional method is limited to what information the sensors pick up. The old methods have no capability of identifying the reconnaissance, which happens very often before potential breaches.
Part Two: The Solution
Most attackers carry cell phones during reconnaissance and the actual breach. This means the chances that a new cellular device will show up near the (potential) breach site is very likely.
I propose a solution of using software-defined radio to simulate cell tower signals within a short range, near the protected perimeters of a site. Through the analysis of abnormal devices within a certain range of the perimeter, we can:
* Identify potential threats (reconnaissance, following, etc).
* Post-breach investigation (by providing cellular device info).
* Conviction (crime scene presence through the location of the device).
Part Three: Technical Implementation Details
SDR Configuration
* (The following SDR config is done only to a short range around the protected perimeter.)
* Use SDR to simulate the cell tower within a short range.
* SDR will force cell phones to downgrade to 2G for information gathering.
* Frequency to power on the SDR. The SDR will NOT always be powered on. It only powers on every 30 minutes, for 1 minute.
* SDR will capture the phone number, active time, and location (directions related to the SDR).
Data Storage
The following data will be stored and encrypted:
* Phone number
* Active time
* Location (relative to the SDR)
Data Analysis
* Normal pattern (learning process): 1) Devices frequently showing up near perimeter (neighbours). 2) Devices only showing up at certain times of the day (mail delivery, garbage pickup, etc).
* Exception pattern: Devices near perimeter that have never show up before (potential reconnaissance).
Identify intrusion: Devices inside the perimeter that have never show up before.
* Correlating the exception pattern with intrusion: identify and note the reconnaissance activity.
Part Four: Limitations and Thoughts
Limitations
* The solution assumes attackers carry cellular device during the recon or breach.
* The location and direction of the device is based on signal strength and is therefore not guaranteed to be accurate.
Integrate with Other Solutions
* Integration with existing perimeter defense solutions
* Trigger the action of drones for 1) vehicle identification 2) real time images
Part Five: Video Demo
Disclaimer:
This article and any related technical detail was prepared or accomplished by the author in his personal capacity. The opinions expressed in this article are the author's own and do not reflect the view of author’s employer
Everyone who has used, or attempted to use, OWASP ModSecurity Web Application Firewall knows something about fine-tuning rules. ModSecurity Core Rule Set (CRS) was designed to catch more, show more and let you decide what to do with security alerts. It is a time consuming -- and often frustrating -- exercise to analyze alerts, separating the wheat from the chaff, and determine which are candidates for blocking.
With thousands of servers at more than 100 locations, Verizon Edgecast CDN is one of the world’s largest deployment of OWASP Core Rule Set. We will share our experience in fine-tuning the CRS for a large number of customers, adjusting to their taste in risk and attitude toward false positives. We will discuss lesser used features of ModSecurity to cut down noise levels in alerts, sometimes as much as 90%. We will also discuss our experience in moving from CRS 2.2.9 to 3.0 which was released in late 2016.
We hope that the audience will walk away with understanding benefits of using the venerable web application firewall with the latest enhancements and issues to consider to get the most out of it. Ultimately, we hope that our experience will make your task of fine-tuning the CRS a little easier.
A Secure Product Lifecycle (SPLC) is integral in ensuring software is written with security in mind, but companies struggle to create a successful process with limited security resources and minimal impact to engineering teams. This session will discuss lessons learned, soup-to-nuts, through the process of designing, rolling out, and measuring a scalable SPLC.
In Adobe’s Digital Marketing business unit, two security analysts created a successful program that has scaled to support thousands of engineers. Defining security requirements and KPIs for engineering teams is just the first step in creating the SPLC. In order to make the design a reality for several products, thousands of engineers, and millions of lines of code, we organized our team into an ‘as a service’ model and utilized automation to scale to meet this demand. Establishing a strong security ambassador program helped ensure the success of the SPLC. The centralized ambassador network has been crucial to the success all product security initiatives throughout the business unit. We will give examples of how ambassadors have assisted with incident response, driven training and security culture initiatives, and have championed security-related projects on their individual team.
We will explore a case study of one of our most successful SPLC-driven programs - static code analysis. By fully automating the process from code check-in to delivery of results, we achieved 100% buy-in from all engineering teams in the Digital Marketing business unit. The process was designed to have minimal impact on the engineering teams, and to be integrated into their existing workflows, allowing for a very low-overhead program that adds value. The engineers code and commit as they normally would. On the backend, our static code analysis engine is scanning and will inject any findings into their existing bug-tracking system.
You will walk away from this talk with on-the-ground knowledge to establish an effective SPLC by establishing and utilizing security ambassadors and providing seamless automation to support these key initiatives.
Crowdsourcing security aka Bug Bounty Programs are adapted by almost all companies today: big, small, mid size. While companies reap a lot of benefits, the challenge is to have a security engineer/engineers reproduce each of the bug, understand the replication method and spend time recreating the security bug that the researcher reported. And sometimes (read all the time) it may also require a lot of going back and forth with the researcher to reproduce the vulnerability. As security engineers we felt the pain as well and we created a tool that solves this challenge and helps organization focus their resources on resolving these vulnerabilities and strengthening their security posture.
Our tool is an open source software and an easy to install chrome/firefox extension. A researcher can install this extension on their browser and record the entire walkthrough of the vulnerability. Our tool captures not only the screen but even Network requests. So, a researcher can capture the entire session and submit this video to the organization. Then the security engineers who validate this can play the video on the tool and see the exploit in action. This makes triaging much easier, saving engineers valuable time. We will be releasing this tool to the community.
During the past 7 years, I have examined how cryptography has been used in 200+ different projects from a security risk perspective. This includes 85+ design reviews well over 100 secure code reviews (mostly Java with some C/C++ and C# thrown in for good measure) performed for two different companies. That includes both proprietary code of these 2 companies, proprietary vendor code reviewed under NDAs, as well as some FOSS code. This talk explores the most commonly observed applied cryptography mistakes made by developers during that 7 year window, how you can spot those mistakes, and finally describes how to correct them.
CSRF vulnerability is one among the OWASP top 10 and detection of this vulnerability in web applications has proved to be a difficult problem. Most dynamic application security testing tools provide the option of scanning for CSRF vulnerability, however their reports are often plagued with either false positives or false negatives making them quite unreliable. In this presentation we will analyze the general approach taken by the tools for CSRF vulnerability detection and identify the reasons behind their failures. Then we propose a new programmatic approach to scan for CSRF vulnerability that overcomes these shortcomings. We will demonstrate that this approach is not only simple and reliable but also can easily be integrated with automated testing for application security.
SaaS-first businesses like Salesforce, Box, Hubspot, Wix, ServiceNow, and Workday are taking over. It’s actually becoming risky for enterprise software companies NOT to adopt the SaaS technology and business model. There’s a real fear of being left behind. Over the next 10–20 years, every software company will be a SaaS company.
As a software-as-a-service company, Egnyte is innovating fast. It’s all about speed of innovation, design, and usability. The faster you can go, the less you spend on product development, and the fewer person hours are required to deliver a complete solution. Every iteration is an opportunity to deliver greater business value.
The problem with buying a SaaS solution from someone you don’t know is trust. When you don’t have a long-term, heavily invested relationship with your customers (as in the old-school IT-driven, on-premise local data center implementation model), how do you signal quality? Elements like security and regulatory compliance must be maintained, but the way they are implemented can’t slow the business down.
At Egnyte, we publish new software updates, features, and enhancements every two weeks. Secure software is business critical, and application security is what really matters. When it comes to software security, I am reasonably confident in our internal release criteria, which includes quality assurance and regression tests, automated security checks, as well as regular periodic software security assessment scans on our public-facing and production applications. But automated tools can’t find everything. Human powered security testing is necessary, and on-demand specialization wins.
Join Kris Lahiri, CISO of Egnyte, for an in depth discussion of the evolution of his software security program - what he tried, what worked, what didn’t, and how he’s planning to move forward. This session is a must-see for any security leader responsible for application security at a Saas company.
In an age of ever more sophisticated cybercrime and mass surveillance secure communication is an increasingly rare premium commodity. In this talk we take a look at how the threat model for secure messaging applications has evolved beyond the traditional man-in-the-middle attacker.
We will cover new goals and capabilities of attackers targeting modern communications networks. We will also look at several classes of attacks many of which are already being used effectively in the wild. For these, we will cover the capabilities needed to launch the attack, the effects successful execution can entail.
Some of the real world attacks/vulnerabilities we will touch upon are:
- The account enumeration and hijacking of Telegram accounts in Iran.
- Detecting the language in encrypted text messages.
- Recovering the content of encrypted VoiP conversations.
- HipChat server compromise leading to leak of meta-data and chat logs.
- Invisible rekeying on WhatsApp.
- Widespread lack of even basic privacy in the face of future quantum attacks.
- Browser based attacks on WhatsApp and Telegram.
- iMessage protocol attack
SQL Injection has long been a common dangerous vulnerability found in many web applications. But many modern web applications forgo the use of SQL in favor of more modern databases commonly referred to as “NoSQL” databases. These databases don’t just use different storage engines, but also provide different query language. Some of the limitations imposed by the query language make traditional injection attacks less likely. But with different query languages and probably even more importantly different more complex datatypes come new classes of vulnerabilities which in the end can be as dangerous and exploitable as SQL injection. In addition, many of these new databases lack some of the more granular security and access controls developers are accustomed to from traditional SQL databases. In this talk, we will survey popular NoSQL databases to compare different threats an application may be exposed to by using these databases. We will also demonstrate some new attacks that instead of focusing on injection of query language commands take advantage of new complex data types like JSON and how they can be manipulated to bypass application level access controls to access or manipulate data.
Best practices for HTTPS deployment have been steadily improving over the past decade. TLS usage on web servers has been steadily increasing and there are dozens of tools (O-Saft being the most popular) now available to test the correctness of the TLS configuration of a front-end web server. All good news. But what about the other services and protocols used in a web application stack? What about the connection between the web application server and the backing data store? Unfortunately, the state of the art regarding proper TLS configuration in popular databases has not progressed as quickly as it has for HTTPS.
Virtually all important data sent between a client and a web application, will also be sent between the application server and its backing data store. The network IS hostile and any connection to the backing data store of a web application needs to have the same level of network confidentiality and integrity as the front-end client.
This talk will look at the current TLS capabilities of popular web application data stores (MySQL, PostgreSQL, and MongoDB), including both the most recent versions as well as the most widely deployed versions. We’ll discuss best practices for defining TLS configuration within these data stores, which are somewhat different from HTTPS, and improvements in tools made by the presenter, to help verify proper server configuration of TLS. Finally, with these new tools we’ll survey actual TLS configurations of publicly connected data stores to determine adherence to best practices in the wild.
Many web applications contain security vulnerabilities that enable attackers to access sensitive data or gain control of client computers or the servers on which those applications are running. These vulnerabilities are caused by web applications failing to correctly sanitize input data and to safely format output data. Many tools and techniques have been created to detect and correct these problems in web applications written using widely-used programming languages such as PHP and Java but little has been done to address vulnerabilities in web applications written using aspect-oriented languages such as AspectJ. This presentation will introduce a new method of detecting potential vulnerabilities in aspect-oriented web applications.
Containers make it easier to deploy the applications that drive business value, but also profoundly challenge existing security models. Learn from our journey as a security team that went from not knowing what containers were to championing their adoption in our production sensitive information workloads over traditional DevOps application deployments.
• About Us
• Our Application & Security Challenges
• Our Container Journey
• Building an Container Ecosystem
• Learning Secure Application Containers
• Benefits for DevOps and Security
• Our Container Security Maturity Model
• What’s Next
For more than a decade, independent arms of the federal government have published application and hardware security standards that only a minor subset of the InfoSec community has a true grasp on. The Federal Information Processing Standard (FIPS) 140-2 contains 11 comprehensive security requirement areas, and the National Information Assurance Directive (NIAP) has created Common Criteria Protection Profiles for Network Devices and Applications that address many of the security threats and design issues that are still persistent today. These standards take a detailed and secure-by-design approach to security that could be hugely beneficial to engineers and system architects beginning to design new systems. Yet, because of the dense and academic style of these standards, many are only vaguely aware of them, seeing them only as a headache forced onto them by sales managers as development is wrapping up.
For three years I worked to formally validate products against these standards, and recently I’ve made the switch to application security assessment where I see many product teams entirely unaware of these practices and standards. This talk aims to cherry-pick the crucial security requirements and principles in these standards and present them in an easily understandable format for development teams, product architects, and security engineers. My goal is to improve your security throughout development and reduce risk for both your customers and company.
I will start by briefly discussing the standards themselves and the context in which they were created and still apply.
Next, I will dive into detail on 5 major security principles that are seen throughout these standards. As I discuss these I will include examples and my observations on how they are currently implemented in the industry.
1. Define the security boundary
2. Create a functional specification
3. Prove that the boundary and services protect Critical Security Parameters
4. Protect all network traffic using SSH, TLS, or IPsec
5. Prove the strength of your entire cryptographic stac
Current Man-in-the-Browser (MITB) trojans like Trickbot or Dridex are pretty much similar to first generation bots like Zeus or Zbot. They all include a list of targets and corresponding webinjects and still offer essentially the same features such as keylogging, form-data harvesting, and remote control (RAT) capabilities.
Today, we are seeing a number of client-side defense proposals being rushed through the standardization process, such as CSP, Subresource Integrity and HPKP. In part, these standards are a response to the permissiveness of the browser against injection attacks.
We argue that it is important to understand how effective these standards can be against MITB attacks specifically and anticipate how attackers will evolve the MITB trojans in an attempt to defeat those defenses.
In this talk, based on our work, we fast-forward to a not so distant future of MITB attacks by demoing a home grown MITB trojan that: 1) is resistant to a number of current defenses by tampering with headers and by exploiting JavaScript code polymorphism; 2) holds capabilities that range from credential and data leakage to website hijacking. We'll also cover approaches to defeat these next-gen trojans by employing similar code attacking techniques and demoing how to detect and react to these trojans.
This talk is organized in four sections: 1) Man-in-the-Browser (MITB) evolution, 2) Client-side defenses, 3) Crafting the next-gen MITB trojan, and 4) Conclusions and future work.
In the first section, we will present a quick chronological evolution of MITB trojans. We will review important concepts like Browser Helper Objects (BHO), Web Injects, Form Grabbing, Stored data exfiltration, keylogging, etc. Most of these concepts are still relevant as current generation MITB trojans are still very similar to first generation bots like Zeus.
We will focus on some capabilities that were added to trojans to bypass defenses. Even though through the years, they evolved very little, we have seen some trojans moving from static to dynamic webinjects, allowing the attack to adjust to the rollout of new defenses; we have seen them become more resilient to AVs and to static and dynamic analysis; employing Domain Generation Algorithms (DGA) to remain connected with their C&Cs; and even trojans that are able to tamper with HTTP headers (e.g. Tinba). Other traits such as the use of reverse connections via proxy and Remote Access (RAT) capabilities will be covered too.
In section 2, we will cover a number of different defense mechanisms/techniques - some of which are still being standardized - such as Content Security Policy (CSP), Subresource Integrity, JavaScript Sandboxing, WAFs, User behavior analytics and Device Fingerprinting. We will discuss how effective they can be against current MITB attacks and where they fall short. We will draw strategies that can be followed by MITB trojans to defeat or bypass these defenses/techniques.
In section 3, we will dive into the goodies. We will present the capabilities we have designed using a modified implementation of Zeus. These capabilities include HTTP header manipulation, to for instance defeat CSP and other types of defenses based on HTTP headers; the use of metamorphic and polymorphic JavaScript, to avoid detection; etc. We will also explore advanced scenarios like the use of HPKP suicide attacks conveyed by MITB trojans. A demo of our Trojan will be shown at this point.
In section 4, the discussion will move on to identify the strategies that can be followed to fight our bot. We will give our opinion on where the appsec community needs to focus next, in order to be prepared for more sophisticated MITB attacks. We’ll draw our conclusion and present our ideas for future work.
Building secure applications is a difficult task, especially in combination with building it based on a new application framework. ASP.NET Core is a new open-source and cross-platform framework completely rewritten from scratch. It can run on Windows, Mac and Linux and the framework moved to a more modular based approach which gives more flexibility when creating solutions with it.
How secure is ASP.NET Core by default? Do the API’s help the developer out doing a good job or is a mistake easily made? In this session, we're going to investigate how ASP.NET Core MVC deals with the above questions related to e.g. Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) issues. We’re also going to extend it and adapt new web standards and see how we can validate an existing solution for the problems we’ve identified.
We have been conducting ongoing research on the dynamics of credential theft. Our intent was to learn about how accounts are being taken over once credentials are compromised through a Phishing campaign. It is a "victim's POV" approach to Phishing research that has not been taken to date.
In our "beyond takeover" research, we maintained 57 fake identities through a period of 6 months in platforms well-known as phishing targets like Google and Facebook. We invited attackers in by admitting the credentials of these accounts to selected phishing campaigns and traced the activity of the attackers in the accounts.
In this session, we will share our findings from this research. We will present takeover stories and some statistics for interesting questions. After falling into a phishing trap and giving one's password to a fake site, how long does is take until someone will actually get into his or her account for the first time? What does the attacker look for in the hacked account? Where do they look first and which decoys attract their attention? Which security practices do attackers use when sniffing out a hacked account (hiding their geo-location or covering their tr
The incorporation of DevOps within a large enterprise is generally accomplished through strategic planning on the organizational level. Having a common pipeline for Continuous Integration (CI) and Continuous Deployment (CD) can enhance the security posture of an application and enable organizations to rapidly release applications into production. However, the insertion of application security in the pipeline is only one step of a multidimensional application security approach.
In this presentation, we will describe our implementation of two complementary methods, which have allowed us to provide the scalability and coverage required in order to meet the needs of a large enterprise. The first method utilizes a tool written in Java to allow for easy integration with your build. We will demonstrate how to deploy and use a dynamic scanner within a Continuous Integration (CI) and Continuous Deployment (CD) pipeline. The second method leverages the data collected from analytic tools such as Splunk, LogStash, Tealeaf and SiteCatalyst. Through the utilization of containers, we will demonstrate how a RESTful API service can be implemented to perform a quick analysis of applications to ensure basic security requirements are met on a large scale. An example will be presented utilizing a RESTful API service to enhance our continuous scanning platform with multiple scanning technologies.
Implementing these solutions has transformed the way we assess our applications. Using the first method we were able to present a dynamic scanning solution to all of our applications that support automated regression testing. Our second method has enabled us to effortlessly scan over 2000 urls in less than 2 hours to provide a quick look at the security of all of our exposed urls. It is essential to put security on the forefront of organizational structure and to ensure that dynamic analysis is part of all build cycles
The consequences of not complying with the requirements of General Data Protection Regulation (GDPR) is immense for all international data processors. The fines and penalties even for small companies can be as high as 20 million EUR, and GDPR requires data protection by design and by default. Most IT companies do not have in-house expertise to identify the required features for full compliance. This work provides a valuable vendor and technology-agnostic toolkit for building GDPR-complaint software with minimum cost and effort. The toolkit is based on a tag-based approach for identifying required features and tasks. After reviewing various privacy regulations, including GDPR, and coding their content, we arrived at a set of tags that fully capture the principles and notions of privacy requirements relevant to software development, deployment and operation. The tags are organized in 14 classes and include sub-tags, and variants. Any list of privacy and security controls can be evaluated using these tags to ascertain if they adequately enable the desired level of privacy. As a case study we will develop the first publicly available agile scrum template, using the proposed tagging system, for the development of an IoT system that transmits private information across the international borders. The tagging system and the approach could be easily customized for any other agile methodology and framework. The talk will expand on some of the recent stories and case studies of how missing the tags can create non-compliance and as a result, huge liability.
Global organizations have been working off of a broken or non-existent threat model. Distracted with compliance, plagued with undefined attack surfaces, a deluge of inoperable threat intel, risk distortions, and made complacent by a sea of controls, *Sec practitioners should feel compelled to reboot their approach. This talk will exemplify how key OWASP projects can truly bootstrap the smallest of *Sec groups to make a measurable impact to applying security through measurable technology in lieu of security smokescreens that plague our industry. Come hear an OWASP commission for change and hear how an OWASP security mesh can exemplify a model that can be imitated by audience members to apply to their own respective security programs and overall companies.
