APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Security Testing: The Next Step in Modernizing AppSec
Scott Gerlach, Co-Founder, Chief Security Officer at StackHawk
apidays LIVE New York 2021 - Why Software Teams Struggle with API Security Te...apidays
apidays LIVE New York 2021 - API-driven Regulations for Finance, Insurance, and Healthcare
July 28 & 29, 2021
Why Software Teams Struggle with API Security Testing
Scott Gerlach, Co-Founder & Chief Security Officer at StackHawk
There are many types of automatic tests, testing tools, libraries and approaches.
Automatic tests can save you a lot of stress but can also became a kind of a nightmare.
This presentation is an overview of what's available and how to use and not to use them to make them really useful.
Examples taken from PHP world. You might be surprised how many tools is available.
apidays LIVE New York 2021 - Why Software Teams Struggle with API Security Te...apidays
apidays LIVE New York 2021 - API-driven Regulations for Finance, Insurance, and Healthcare
July 28 & 29, 2021
Why Software Teams Struggle with API Security Testing
Scott Gerlach, Co-Founder & Chief Security Officer at StackHawk
There are many types of automatic tests, testing tools, libraries and approaches.
Automatic tests can save you a lot of stress but can also became a kind of a nightmare.
This presentation is an overview of what's available and how to use and not to use them to make them really useful.
Examples taken from PHP world. You might be surprised how many tools is available.
Security process should be integrated with SDLC well to be successful. While many companies have already moved from Waterfall to Agile methodologies security remains behind more often than not. We have demonstrated in our presentation how security can move to agile by utilizing open source tools, customizing them to meet our needs and to implement a continuos security testing using dynamic scanners as well as manual testing.
It’s very important also to assure that false positives are not fed to the developers bug tracking systems and to assign a severity for each finding correctly. To make it happen we import all our findings to a security dashboard and review them before exporting to a bug tracking system.
I have had the unique opportunity over the few years to work on multiple API initiatives and observe and learn from several seasoned API practitioners. Even though API First and Design First and principles are generally well understood, I have noticed time and again that even the most well intentioned launch API products that ultimately fail to win over developers. In this session, I aim to share lessons that I have learnt, mistakes that I have made or seen others make with a goal that you the audience can reflect on API’s you already have or about to launch and learn from such mistakes.
So you wanna be a pentester - free webinar to show you howJoe McCray
I’ll be covering things like:
- Some of the various types of penetration testing jobs
- Education/Certification/Experience/Skill requirements
- Should I have a degree – if so what type?
- Should I have certifications – if so which ones?
- Should I have work experience – if so what type?
- What skills should I have prior to applying?
- Do I need to be a good programmer?
- Where can I get these skills if I’m not currently working in the field?
- Security clearance requirements
- What are good key words to use when searching IT job sites for pentesting jobs?
- What to expect during the interview process
- I’m not in the US, where can I find pentester work abroad?
- How much money can I expect to make as a pentester?
- The good the bad and the ugly…what the work is actually like day-in and day-out
The Dev, Sec and Ops of API Security - API World42Crunch
The enterprise use of APIs is growing exponentially. Companies face a difficult choice. They must shift towards a software-based, digital approach to service and product delivery – or get left behind. Agile development, business pressure and the complexity of API security have made security teams life very complicated. And to make matters more complicated, the adoption of microservices architectures has multiplied the number of API endpoints that you have to protect.
Downside: The more APIs, the higher the security risk!
API security flaws are injected at many different levels of the API lifecycle: in requirements, development, deployment and monitoring. It is proven that detecting and fixing vulnerabilities during production or post-release time is up to 30 times more difficult than earlier in the API lifecycle. Security should be easy to considered at requirements phase, applied during development by attaching pre-defined policies to APIs and ensuring that security tests are performed as part of the continuous delivery of the APIs.
Upside: We’ll prep you with all the knowledge and tools you need to implement an automated, end-to-end API Security process that will get your dev, sec and ops teams speaking the same language.
In this presentation you will learn:
Security risks at each stage of the API lifecycle, and how to mitigate them.
How to implement an end-to-end automated API security model that development, security and operations teams will love.
How to think positive! Why a positive security model works.
apidays LIVE Paris 2021 - Addressing OWASP API Security Top 10 by Isabelle Ma...apidays
pidays LIVE Paris 2021 - APIs and the Future of Software
December 7, 8 & 9, 2021
Addressing OWASP API Security Top 10 starts at design time
Isabelle Mauny, Field CTO & Co-Founder at 42Crunch
Security engineering 101 when good design & security work togetherWendy Knox Everette
Security concerns are often dealt with as an afterthought—the focus is on building a product, and then security features or compensating controls are thrown in after the product is nearly ready to launch. Why do so many development teams take this approach? For one, they may not have an application security team to advise them. Or the security team may be seen as a roadblock, insisting on things that make the product less user friendly, or in tension with performance goals or other business demands. But security doesn’t need to be a bolt-on in your software process; good design principles should go hand in hand with a strong security stance. What does your engineering team need to know to begin designing safer, more robust software from the get-go?
Drawing on experience working in application security with companies of various sizes and maturity levels, Wendy Knox Everette focuses on several core principles and provides some resources for you to do more of a deep dive into various topics. Wendy begins by walking you through the design phase, covering the concerns you should pay attention to when you’re beginning work on a new feature or system: encapsulation, access control, building for observability, and preventing LangSec-style parsing issues. This is also the best place to perform an initial threat model, which sounds like a big scary undertaking but is really just looking at the moving pieces of this application and thinking about who might use them in unexpected ways, and why.
She then turns to security during the development phase. At this point, the focus is on enforcing secure defaults, using standard encryption libraries, protecting from malicious injection, insecure deserialization, and other common security issues. You’ll learn what secure configurations to enable, what monitoring and alerting to put in place, how to test your code, and how to update your application, especially any third-party dependencies.
Now that the software is being used by customers, are you done? Not really. It’s important to incorporate information about how customers interact as well as any security incidents back into your design considerations for the next version. This is the time to dust off the initial threat model and update it, incorporating everything you learned along the way.
Identified by OWASP as one of the top-10 security threats facing developers, Underprotected APIs are subject to common exploitation that can be difficult to detect. This presentation outlines the reasoning and methodology behind securing these APIs. By Adam Cecchetti, CEO of Deja vu Security
Test execution is the process of executing the code and comparing the expected and actual results. Following factors need to be considered for a test execution process − Based on a risk, select a subset of test suite to be executed for this cycle. Assign the test cases in each test suite to testers for execution.
#ATAGTR2018 Presentation " Security Testing for RESTful APIs" By Anuradha Raman Agile Testing Alliance
Anuradha Raman who is a QA Lead at Encore Software Services took a Session on "Security Testing for RESTful APIs" at Global Testing Retreat #ATAGTR2018
please refer our linkedin post for session details
https://www.linkedin.com/pulse/security-testing-restful-apis-anuradha-raman-agile-testing-alliance/
2022 APIsecure_A day in the life of an API; Fighting the oddsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
A day in the life of an API; Fighting the odds
Gil Shulman, VP Technologies at Wib
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
The Real World, API Security Edition: When best practices stop being polite and start being real
Sean Boulter, Principal Security Engineer at Salt Security
2022 APIsecure_Learn from the Past, Secure the Present, Plan for the Future: ...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Learn from the Past, Secure the Present, Plan for the Future: API Vulnerabilities
Hila Zigman-Zinshtein, VP Product at Noname Security
More Related Content
Similar to 2022 APIsecure_API Security Testing: The Next Step in Modernizing AppSec
Security process should be integrated with SDLC well to be successful. While many companies have already moved from Waterfall to Agile methodologies security remains behind more often than not. We have demonstrated in our presentation how security can move to agile by utilizing open source tools, customizing them to meet our needs and to implement a continuos security testing using dynamic scanners as well as manual testing.
It’s very important also to assure that false positives are not fed to the developers bug tracking systems and to assign a severity for each finding correctly. To make it happen we import all our findings to a security dashboard and review them before exporting to a bug tracking system.
I have had the unique opportunity over the few years to work on multiple API initiatives and observe and learn from several seasoned API practitioners. Even though API First and Design First and principles are generally well understood, I have noticed time and again that even the most well intentioned launch API products that ultimately fail to win over developers. In this session, I aim to share lessons that I have learnt, mistakes that I have made or seen others make with a goal that you the audience can reflect on API’s you already have or about to launch and learn from such mistakes.
So you wanna be a pentester - free webinar to show you howJoe McCray
I’ll be covering things like:
- Some of the various types of penetration testing jobs
- Education/Certification/Experience/Skill requirements
- Should I have a degree – if so what type?
- Should I have certifications – if so which ones?
- Should I have work experience – if so what type?
- What skills should I have prior to applying?
- Do I need to be a good programmer?
- Where can I get these skills if I’m not currently working in the field?
- Security clearance requirements
- What are good key words to use when searching IT job sites for pentesting jobs?
- What to expect during the interview process
- I’m not in the US, where can I find pentester work abroad?
- How much money can I expect to make as a pentester?
- The good the bad and the ugly…what the work is actually like day-in and day-out
The Dev, Sec and Ops of API Security - API World42Crunch
The enterprise use of APIs is growing exponentially. Companies face a difficult choice. They must shift towards a software-based, digital approach to service and product delivery – or get left behind. Agile development, business pressure and the complexity of API security have made security teams life very complicated. And to make matters more complicated, the adoption of microservices architectures has multiplied the number of API endpoints that you have to protect.
Downside: The more APIs, the higher the security risk!
API security flaws are injected at many different levels of the API lifecycle: in requirements, development, deployment and monitoring. It is proven that detecting and fixing vulnerabilities during production or post-release time is up to 30 times more difficult than earlier in the API lifecycle. Security should be easy to considered at requirements phase, applied during development by attaching pre-defined policies to APIs and ensuring that security tests are performed as part of the continuous delivery of the APIs.
Upside: We’ll prep you with all the knowledge and tools you need to implement an automated, end-to-end API Security process that will get your dev, sec and ops teams speaking the same language.
In this presentation you will learn:
Security risks at each stage of the API lifecycle, and how to mitigate them.
How to implement an end-to-end automated API security model that development, security and operations teams will love.
How to think positive! Why a positive security model works.
apidays LIVE Paris 2021 - Addressing OWASP API Security Top 10 by Isabelle Ma...apidays
pidays LIVE Paris 2021 - APIs and the Future of Software
December 7, 8 & 9, 2021
Addressing OWASP API Security Top 10 starts at design time
Isabelle Mauny, Field CTO & Co-Founder at 42Crunch
Security engineering 101 when good design & security work togetherWendy Knox Everette
Security concerns are often dealt with as an afterthought—the focus is on building a product, and then security features or compensating controls are thrown in after the product is nearly ready to launch. Why do so many development teams take this approach? For one, they may not have an application security team to advise them. Or the security team may be seen as a roadblock, insisting on things that make the product less user friendly, or in tension with performance goals or other business demands. But security doesn’t need to be a bolt-on in your software process; good design principles should go hand in hand with a strong security stance. What does your engineering team need to know to begin designing safer, more robust software from the get-go?
Drawing on experience working in application security with companies of various sizes and maturity levels, Wendy Knox Everette focuses on several core principles and provides some resources for you to do more of a deep dive into various topics. Wendy begins by walking you through the design phase, covering the concerns you should pay attention to when you’re beginning work on a new feature or system: encapsulation, access control, building for observability, and preventing LangSec-style parsing issues. This is also the best place to perform an initial threat model, which sounds like a big scary undertaking but is really just looking at the moving pieces of this application and thinking about who might use them in unexpected ways, and why.
She then turns to security during the development phase. At this point, the focus is on enforcing secure defaults, using standard encryption libraries, protecting from malicious injection, insecure deserialization, and other common security issues. You’ll learn what secure configurations to enable, what monitoring and alerting to put in place, how to test your code, and how to update your application, especially any third-party dependencies.
Now that the software is being used by customers, are you done? Not really. It’s important to incorporate information about how customers interact as well as any security incidents back into your design considerations for the next version. This is the time to dust off the initial threat model and update it, incorporating everything you learned along the way.
Identified by OWASP as one of the top-10 security threats facing developers, Underprotected APIs are subject to common exploitation that can be difficult to detect. This presentation outlines the reasoning and methodology behind securing these APIs. By Adam Cecchetti, CEO of Deja vu Security
Test execution is the process of executing the code and comparing the expected and actual results. Following factors need to be considered for a test execution process − Based on a risk, select a subset of test suite to be executed for this cycle. Assign the test cases in each test suite to testers for execution.
#ATAGTR2018 Presentation " Security Testing for RESTful APIs" By Anuradha Raman Agile Testing Alliance
Anuradha Raman who is a QA Lead at Encore Software Services took a Session on "Security Testing for RESTful APIs" at Global Testing Retreat #ATAGTR2018
please refer our linkedin post for session details
https://www.linkedin.com/pulse/security-testing-restful-apis-anuradha-raman-agile-testing-alliance/
2022 APIsecure_A day in the life of an API; Fighting the oddsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
A day in the life of an API; Fighting the odds
Gil Shulman, VP Technologies at Wib
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
The Real World, API Security Edition: When best practices stop being polite and start being real
Sean Boulter, Principal Security Engineer at Salt Security
2022 APIsecure_Learn from the Past, Secure the Present, Plan for the Future: ...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Learn from the Past, Secure the Present, Plan for the Future: API Vulnerabilities
Hila Zigman-Zinshtein, VP Product at Noname Security
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Shift Left API Security- The right Way
Sanjay Nagaraj, CTO and Co-Founder at Traceable
2022 APIsecure_Passwordless Multi-factor Authentication Security and IdentityAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Passwordless Multi-factor Authentication Security and Identity
Sal Karatas, CEO at SAASPASS
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Securing Large API Ecosystems
Michal Trojanowski, Product Marketing Engineer at Curity AB
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Quarterly Review of API Vulnerabilities
Ivan Novikov, CEO at Wallarm
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Top Ten Security Tips for APIs
Tanya Janca, CEO and Founder at WeHackPurple
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Are your APIs Rugged Enough?
Colin Domoney, Developer Advocate & API Security Researcher at 42Crunch
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Making webhook APIs secure for enterprise use
Liam Forde, Founder and Head of Product at webhookie
2022 APIsecure_API Security & Fraud Detection - Are you ready?APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Security & Fraud Detection - Are you ready ?
Amandine Elbaze, Cyber Security Consultant - API Fraud Detection SOAR at Cybersolutions
Dan Farache, Strategy Advisor for API SECURITY & SOAR
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Monitoring and Responding to API Breaches
Carolina Ruiz, CEO at Brier & Thorn
2022 APIsecure_Exploiting multi-step business logic vulnerabilities in APIsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Exploiting multi-step business logic vulnerabilities in APIs
Inon Shkedy, API Security Project Lead at OWASP
2022 APIsecure_Realizing the Full Cloud Native Potential With a Multi-Layered...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Realizing the Full Cloud-Native Potential With a Multi-Layered Defense Approach
Ory Segal, Sr. Director & Product Management at Palo Alto Networks
2022 APIsecure_From Shift Left to Full Circle - A Pragmatic Approach to Catch...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
From Shift Left to Full Circle - A Pragmatic Approach to Catching Up and Keeping Up With API Security
Chuck Herrin, CTO at WIB
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Hackers with valid or stolen credentials and API security - beyond OWASP top 10
Bernard Harguindeguy, SVP at Ping Identity
2022 APIsecure_API Abuse - How data breaches now and in the future will use A...APIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Abuse - How data breaches now and in the future will use API's as the attack vector
Sudeep Padiyar, Product Manager at Traceable
Tim Davis, Director of Product Management at Chime
2022 APIsecure_Understanding API Abuse With Behavioral AnalyticsAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Understanding API Abuse With Behavioral Analytics
Giora Engel, CEO and Co-Founder, Neosec
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
Harnessing the Speed of Innovation
Jyoti Bansal, CEO & Founder at Traceable
2022 APIsecure_API Discovery: First step towards API SecurityAPIsecure_ Official
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
API Discovery: First step towards API Security
Amod Gupta, Product Manager at Traceable
APIsecure - April 6 & 7, 2022
APIsecure is the world’s first conference dedicated to API threat management; bringing together breakers, defenders, and solutions in API security.
We’re Not in AppSec Anymore Toto, API Security for the Enterprise
Alyssa Miller, Business Information Security Officer at Standard & Poor Global Ratings
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
Removing Uninteresting Bytes in Software FuzzingAftab Hussain
Imagine a world where software fuzzing, the process of mutating bytes in test seeds to uncover hidden and erroneous program behaviors, becomes faster and more effective. A lot depends on the initial seeds, which can significantly dictate the trajectory of a fuzzing campaign, particularly in terms of how long it takes to uncover interesting behaviour in your code. We introduce DIAR, a technique designed to speedup fuzzing campaigns by pinpointing and eliminating those uninteresting bytes in the seeds. Picture this: instead of wasting valuable resources on meaningless mutations in large, bloated seeds, DIAR removes the unnecessary bytes, streamlining the entire process.
In this work, we equipped AFL, a popular fuzzer, with DIAR and examined two critical Linux libraries -- Libxml's xmllint, a tool for parsing xml documents, and Binutil's readelf, an essential debugging and security analysis command-line tool used to display detailed information about ELF (Executable and Linkable Format). Our preliminary results show that AFL+DIAR does not only discover new paths more quickly but also achieves higher coverage overall. This work thus showcases how starting with lean and optimized seeds can lead to faster, more comprehensive fuzzing campaigns -- and DIAR helps you find such seeds.
- These are slides of the talk given at IEEE International Conference on Software Testing Verification and Validation Workshop, ICSTW 2022.
3. AppSec Problem Overview
AppSec = Important, but hard and how do you not let this Tech Debt pile
up?
Static Code Analysis
● Noisy, often lacks Application Context
● Language Dependant (Don’t get me started on IDE support)
Dynamic Code Analysis
● Better at actual app and context, but still somewhat noisy
● Hard to use
RASP, IAST, WAF
● Wait til someone/something else finds it… in Prod
5. Hey! I broke the crap out of your thing. Cool huh!
6. working agreement | [wur-king ə-ˈgrē-mənt ]
Definition Time
1. The purpose of a working agreement is to ensure the Agile Team
shares responsibility in defining expectations for how they will function
together and enhance their self-organization process
2. Working agreements can apply to services, and can even be
documented.
3. You can certainly make a working agreement with the Security Team…
just saying
7. Functional Agreements:
● Rate Limiting?
● Standardized Errors?
Data Input:
● Validation?
● Encoding?
● Escaping?
Data Output:
● Validation?
● Encoding?
● Escaping?
● Paging?
Data Working Agreement
Functional Agreements:
● Back off routines?
Data Input:
● Validation?
● Encoding?
● Escaping?
Data Output:
● Validation?
● Encoding?
● Escaping?
Backend Team (API Team) Front End Team
8. Functional Agreements:
● Rate Limiting
● Standardized Errors
Data Input:
● Validation
● Encoding
● Escaping
Data Output:
● Validation
● Encoding
● Escaping
● Paging
Data Working Agreement
Functional Agreements:
● Back off routines
Data Input:
● Validation
● Encoding
● Escaping
Data Output:
● Validation
● Encoding
● Escaping
Backend Team (API Team) Front End Team
YES, THAT!
10. Hey! I broke the crap out of your thing. Cool huh!
FIX ALL THE THINGS!
I think we’ve got a
SQL Injection here
11. Security Websters
Broken Object Level Authorization
Tenancy Filtering
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface
Level Access Control issue. Object level authorization checks should be considered in every
function that accesses a data source using an input from the user
Customer A shouldn’t be able to get to Customer B’s data
12. Let’s Teach Them AppSec
If they know how attackers think, they’ll be able to test like an attacker - Hack Yourself!
● Here’s 11ty Billion new Acronyms to learn
● Also, let’s talk about risk
● But wait before that, do you know the Internet is a bad
place?
● If you have sent any of your Devs to a Security Training
program, who usually gets selected?
13. “We Need to Model Out a Price Increase”
Have you ever seen the FP&A team teach the basics of accounting to the Exec Team
16. Examining the Production-Bias: People
Primary Value: These groups are very focused on the “finding” of vulnerabilities/security bugs. MOAR
findings = MOAR better.
The Security Team Pen Tester
Production is where they know the app the best Production is their only point of access
Repercussions…
● More focused on the numbers of things found, than finding and fixing the right things
● Inefficient — the “finders” are not the “fixers”
● Reinforces an adversarial relationship — “Hey look, I broke your stuff”
*Assuming you have a security team
17. Security is either
a blocker
or “playing catch up”
DEV OPS
Examining the Production-Bias: Timing
18. Production Bias - Pants Problem
Pants `R’ Us
GET /rest/api/v1/listPants
Returns list of pantIds
GET /rest/api/v1/{pantId}/details
Returns details about a pair of pants, size, color, stock
19. Production Bias - Pants Problem
GET /rest/api/v1/listPants
Returns list of pantIds
GET /rest/api/v1/{pantId}/details
Returns details about a pair of pants, size, color, stock
HUNDREDS OF STYLES AND SIZES WAITING FOR YOU!
23. How Test-Driven
Security
Should Work
When a team writes code, they know the syntax
is wrong when it won’t compile.
When a team merges code they know there is a
problem when it doesn’t merge.
When a team runs unit tests, they know the
code is wrong when it fails the unit test.
When a team runs integration tests, they
know the code is wrong when it doesn’t work
as designed.
When a team introduces a
vulnerability, they know when it
fails a security test.
24. DEV OPS
Right Time: Pre-Production
Instrumenting Security Tests into CI/CD
gives engineers immediate feedback.
Adding the ability to test locally allows for
quick iteration in the fix-test loop if a new
bug is identified.
Local Dev & CI/CD
25. ● Set up working agreements across
teams/apps/departments
● Create Standards documentation automatically
(OpenAPI/Introspection)
● If you are in security shopping for AppSec tools, BRING A
DEV with you!
● Seed the database! Test in Pre-Prod!
● Understand these two things deeply
○ Object Level Authorization (ie Tenancy Filtering)
○ Function Level Authorization (ie Admin API access)
Cover Your Bases
26.
27. ● Engage a project team and their pipeline
● Choose AN app or service to start
● Choose a technology (SCA, DAST)
● Iterate and expand
Just Start!
Working agreements just don’t exist between a lot of teams. Let’s dig in a bit more
Working agreements just don’t exist between a lot of teams. Our friends here don’t seme to buy into what we are talking about.
Working agreements are good Mr. Lamar! They can help you keep things straight between teams.
Perhaps you’ve not heard of them or maybe not understand how they relate to API security? Let dig into them a bit more.
Generally a working agreement is a contract or an understanding between two or more parties. This really came up in Agile and Scrum or Product Delivery Teams
Who is in charge of all of these things?
At what point should the front end be encoding data?
If the front end encodes the data, does the back end need to worry about it at all? Don’t forget, that API is probably public.
Who’s to say the Front End is the only thing accessing the API?
Data Shape / Data Contracts
Yes, we should be doing all of these things. HOW you do them is just as important as identifying needing to do them and that’s what should go into the working agreement
The hard truth is, you can never hire as many AppSec people as the organization can hire developers. The Security team often makes this whole thing a lot harder in the name of “accountability”, but really what they are doing at this point is making people go slower or cause interruptions because they can’t scale with the business.
This is what a lot of security tools look like and in fact almost all of the AppSec tools look like this.
If an engineer gained access to a tool that looked like this, they’d probably close it pretty quick OR start making fun of how it was developed. Neither is what you want them to do.
Built in security person language
A developers job is not to learn all of this new stuff, but they have to know how to protect against it and or prevent it.
These are basically the same thing here, obviously there could be more to the Tenancy Filtering, but so many of these definitions are so broadly described, it can be really hard to apply them to a real word scenario
This is at best misguided and at worst continues to drive division between Dev and Security teams. “You don’t know how to do your job, but we can teach you how to do ours...”
It’s the equivalent of accounting saying to leadership, lets teach you about the GL
Because they are built for the security team they inherit another problem
The people that do testing today and the context under which they understand the thing they are testing
As companies are rapidly shipping code to production, security is not baked into this workflow. (Either you’re not rapidly shipping (in which case appsec processes act as a blocker), or the security team is playing catch up)
If the security team is doing release approval, they are acting as blockers.
AppSec tools that run in production are often used infrequently, in <some duration> after a release and are just telling you about the bugs you released in production
There’s a huge problem with this methodology
Here’ an example API. It’s used to display pant details in an online shop. We don’t just sell one kind of pants though
We sell LOTS of pants.
Most tools that are used to scan APIs and Websites like this don’t understand and turn 2 simple API calls into HUNDREDS and can end up taking hours to complete.
Sometimes they do this because we aren’t generating standard specs like OpenAPI Spec and sometimes it’s because the scanner just doesn’t use the specs.
I mean like a LOT! of pants.
Most tools that are used to scan APIs and Websites like this don’t understand and turn 2 simple API calls into HUNDREDS and can end up taking hours to complete.
Sometimes they do this because we aren’t generating standard specs like OpenAPI Spec and sometimes it’s because the scanner just doesn’t use the specs.
The process is so frustrating for software engineers. The security team runs infrequent scans of your code that is already in production.
They then engage in a bunch of ticket shuffling trying to find the engineering team that wrote or can otherwise fix the issue in the code.
That team has long moved on to other engineering work (business value) and they have conflicting priorities - and often security tickets lack the concept of business context as to why they’re important to fix over current spint work. As a product person you’re fighting for roadmap delivery and meeting customer commitments.
May intentionally ship to production making a risk based decision…
There will be lots of times that we will intentionally ship security bugs to production, but the intentionality is the important thing here. This should be done eyes wide open and be a risk based decision. You might know that exposure is limited and it will be fixed in the next sprint. But production should not be the first place that you are checking *if* there are any bugs. <- PREACH!
To combat this trust issue, often times security teams com up with a new great idea
We (security), also have this nasty habit. Often we think of eliminating ALL risk - patch EVERYTHING, don’t do ANYTHING in the cloud, etc.
Businesses exist to take risk. That risk is to provide solutions to customer problems. Heck even thinking you can solve a customers problem is a risk.
Need measured and informed risk to operate, security is no different.
As CTOs, VPs Eng, and Engineering manager or even a Developer, perhaps you’ve been tasked with “Security”. That can lead to one of these things in your head.
It’s easier to start than you think, and we’ll go over that at the end.
And one other, that I know of for sure. Wink wink
A check for security bugs in production is inefficient. Engineers have moved on to other sprint tasks and fixing involves context switching.
Scanning www. Or app. In production makes it difficult to identify the app or service affected, and lacks context of the specific data handled by that service. You end up with ticket shuffling trying to identify the service affected then find the team who owns the service that was affected.
Focus on number of bugs found, and % fixed over time ignores business context of the findings and trade off decisions around business value generation
Might be some good data here about time to fix from other analogs (e.g., unit testing or integration testing)?
The findings often lack business context - How important is this thing to the business?
Should we be fixing ALL of the bugs on an internal application or going fast on that?
How should we think about our apps and the data they handle?
The process is so frustrating for software engineers. The security team runs infrequent scans of your code that is already in production.
They then engage in a bunch of ticket shuffling trying to find the engineering team that wrote or can otherwise fix the issue in the code.
That team has long moved on to other engineering work (business value) and they have conflicting priorities - and often security tickets lack the concept of business context as to why they’re important to fix over current spint work. As a product person you’re fighting for roadmap delivery and meeting customer commitments.
May intentionally ship to production making a risk based decision…
There will be lots of times that we will intentionally ship security bugs to production, but the intentionality is the important thing here. This should be done eyes wide open and be a risk based decision. You might know that exposure is limited and it will be fixed in the next sprint. But production should not be the first place that you are checking *if* there are any bugs. <- PREACH!
Instrumenting Security Tests into CICD gives feedback immediately. Adding the ability to test locally allows engineers to quickly iterate the fix-test loop if a new bug was identified.
would add something about feedback loops - CiCD gives feedback immediately and is configured to run with merge/pr etc - weekly scanning is not that at all… less security bugs make it to production
Our customers check for security bugs on every merge. And have the ability to quickly test locally when troubleshooting a fix.
You can test while you’re writing code, and test while you’re building code… and security tools should play well in these phases of development.
Working agreements make most of this stuff easier. Knowing what the other team is going to do, take a lot of guess work out of your daily job
Having code create documentation for you is your BEST Friend. I’ve spoken with so many company’s that have REST APIs and no API Specification. When I ask them how people in the organization figure out how to integrate with those services, the answers range from Internal Wikis to the read the code base of the API… None of that is efficient AND it makes testing really hard
Testing in Prod has a lot of drawbacks. If you need to test in prod, it should be the triple double stamp, not the only stamp. Test early, test often, test with seed data.
The best tool you can buy, is one the dev team will use and like (let’s not stretch here and say love) - Bring a lead dev or a dev experience or a dev manager with you to do evaluations. Printing outstanding issues to PDF is not doing you any good. Measuring Time to Close in months, is, we’ll it’s a waste of time…
Security tools just don’t understand these things and they are REALLY hard to generically test for. Write tests for these issues, make sure customer A can’t see customer Bs data and make sure you can’t just willy nilly get to the admin section of the API by guessing a path (becasue you documented the path, remember, it’s not secret)
Warning: You may need a few therapy sessions to break down the lack of trust between these teams
Define each appsec tool - high level of how it works
Options open source and commercial
(open source and commercial)
I feel like there could be something here that drills home the how.
Auto check on every merge
Visibility in developer tooling (e.g., Slack)
Reproducibility that developers can use themselves.
It should all live with the developers so they can self serve. This democratizes security.