�ݺ�ߣshows by User: abhaybhargav

�ݺ�ߣshows by User: abhaybhargav / http://www.slideshare.net/images/logo.gif �ݺ�ߣshows by User: abhaybhargav / Fri, 25 Jan 2019 22:59:10 GMT �ݺ�ߣShare feed for �ݺ�ߣshows by User: abhaybhargav An Attacker's View of Serverless and GraphQL Apps - Abhay Bhargav - AppSec California 2019 /slideshow/an-attackers-view-of-serverless-and-graphql-apps-abhay-bhargav-appsec-california-2019/129289800 abhaybhargavappseccalislsgql-190125225910
Serverless Technology (Functions as a Service) is fast becoming the next "big thing" in the world of distributed applications. Organizations are investing a great deal of resources in this technology as a force-multiplier, cost-saver and ops-simplification cure-all. Especially with widespread support from cloud vendors, this technology is going to only become more influential. However, like everything else, Serverless apps are subject to a a wide variety of attack possibilities, ranging from attacks against access control tech like Function Event Injection, JWTs, to NoSQL Injection, to exploits against the apps themselves (deserialization, etc) escalating privileges to other cloud component. On the other hand GraphQL (API Query Language) is the natural companion to serverless apps, where traditional REST APIs are replaced with GraphQL to provide greater flexibility, greater query parameterization and speed. GraphQL is slowly negating the need for REST APIs from being developed. Combined with Serverless tech/Reactive Front-end frameworks, GraphQL is very powerful for distributed apps. However, GraphQL can be abused with a variety of attacks including but not limited to Injection Attacks, Nested Resource Exhaustion attacks, Authorization Flaws among others. This talk presents a red-team perspective of the various ways in which testers can discover and exploit serverless and/or GraphQL driven applications to compromise sensitive information, and gain a deeper foothold into database services, IAM services and other other cloud components. The talk will have some demos that will demonstrate practical attacks and attack possibilities against Serverless and GraphQL applications.]]>
Serverless Technology (Functions as a Service) is fast becoming the next "big thing" in the world of distributed applications. Organizations are investing a great deal of resources in this technology as a force-multiplier, cost-saver and ops-simplification cure-all. Especially with widespread support from cloud vendors, this technology is going to only become more influential. However, like everything else, Serverless apps are subject to a a wide variety of attack possibilities, ranging from attacks against access control tech like Function Event Injection, JWTs, to NoSQL Injection, to exploits against the apps themselves (deserialization, etc) escalating privileges to other cloud component. On the other hand GraphQL (API Query Language) is the natural companion to serverless apps, where traditional REST APIs are replaced with GraphQL to provide greater flexibility, greater query parameterization and speed. GraphQL is slowly negating the need for REST APIs from being developed. Combined with Serverless tech/Reactive Front-end frameworks, GraphQL is very powerful for distributed apps. However, GraphQL can be abused with a variety of attacks including but not limited to Injection Attacks, Nested Resource Exhaustion attacks, Authorization Flaws among others. This talk presents a red-team perspective of the various ways in which testers can discover and exploit serverless and/or GraphQL driven applications to compromise sensitive information, and gain a deeper foothold into database services, IAM services and other other cloud components. The talk will have some demos that will demonstrate practical attacks and attack possibilities against Serverless and GraphQL applications.]]> Fri, 25 Jan 2019 22:59:10 GMT /slideshow/an-attackers-view-of-serverless-and-graphql-apps-abhay-bhargav-appsec-california-2019/129289800 abhaybhargav@slideshare.net(abhaybhargav) An Attacker's View of Serverless and GraphQL Apps - Abhay Bhargav - AppSec California 2019 abhaybhargav Serverless Technology (Functions as a Service) is fast becoming the next "big thing" in the world of distributed applications. Organizations are investing a great deal of resources in this technology as a force-multiplier, cost-saver and ops-simplification cure-all. Especially with widespread support from cloud vendors, this technology is going to only become more influential. However, like everything else, Serverless apps are subject to a a wide variety of attack possibilities, ranging from attacks against access control tech like Function Event Injection, JWTs, to NoSQL Injection, to exploits against the apps themselves (deserialization, etc) escalating privileges to other cloud component. On the other hand GraphQL (API Query Language) is the natural companion to serverless apps, where traditional REST APIs are replaced with GraphQL to provide greater flexibility, greater query parameterization and speed. GraphQL is slowly negating the need for REST APIs from being developed. Combined with Serverless tech/Reactive Front-end frameworks, GraphQL is very powerful for distributed apps. However, GraphQL can be abused with a variety of attacks including but not limited to Injection Attacks, Nested Resource Exhaustion attacks, Authorization Flaws among others. This talk presents a red-team perspective of the various ways in which testers can discover and exploit serverless and/or GraphQL driven applications to compromise sensitive information, and gain a deeper foothold into database services, IAM services and other other cloud components. The talk will have some demos that will demonstrate practical attacks and attack possibilities against Serverless and GraphQL applications. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/abhaybhargavappseccalislsgql-190125225910-thumbnail.jpg?width=120&height=120&fit=bounds" /> Serverless Technology (Functions as a Service) is fast becoming the next "big thing" in the world of distributed applications. Organizations are investing a great deal of resources in this technology as a force-multiplier, cost-saver and ops-simplification cure-all. Especially with widespread support from cloud vendors, this technology is going to only become more influential. However, like everything else, Serverless apps are subject to a a wide variety of attack possibilities, ranging from attacks against access control tech like Function Event Injection, JWTs, to NoSQL Injection, to exploits against the apps themselves (deserialization, etc) escalating privileges to other cloud component. On the other hand GraphQL (API Query Language) is the natural companion to serverless apps, where traditional REST APIs are replaced with GraphQL to provide greater flexibility, greater query parameterization and speed. GraphQL is slowly negating the need for REST APIs from being developed. Combined with Serverless tech/Reactive Front-end frameworks, GraphQL is very powerful for distributed apps. However, GraphQL can be abused with a variety of attacks including but not limited to Injection Attacks, Nested Resource Exhaustion attacks, Authorization Flaws among others. This talk presents a red-team perspective of the various ways in which testers can discover and exploit serverless and/or GraphQL driven applications to compromise sensitive information, and gain a deeper foothold into database services, IAM services and other other cloud components. The talk will have some demos that will demonstrate practical attacks and attack possibilities against Serverless and GraphQL applications.

An Attacker's View of Serverless and GraphQL Apps - Abhay Bhargav - AppSec California 2019 from Abhay Bhargav

]]> 2491 3 https://cdn.slidesharecdn.com/ss_thumbnails/abhaybhargavappseccalislsgql-190125225910-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation /slideshow/threatmodelingascode-threatplaybook-appsecusa-2018-presentation/119170907 appsecusa2018abhaybhargav-181012035244
Threat Modeling is critical for Product Engineering Team. Yet, even in the rare event that it’s performed, its performed without actionable outputs emerging from the exercise. It is relegated to the status of what a “Policy/Best Practice Document”, which it shouldn’t be. I believe that Threat Models are playbooks of Product Security Engineering. I feel that the best way to do threat modeling is to integrate it into the Software Development Lifecycle (SDL). In addition, I believe that Threat Models should produce actionable outputs that can be acted up on by various teams within the organization. To address this lacuna, I have developed “Automaton” - An Open Source “Threat Modeling as Code” framework, that allows product teams to capture User Stories, Abuser Stories, Threat Models and Security Test Cases in YAML Files (like Ansible). With the help of Test Automation Frameworks (in this case, Robot Framework) Automaton allows the product engineering team to not only capture Threat Models as code, but also trigger specific security test cases with tools like OWASP ZAP, BurpSuite, WFuzz, Sublist3r, Nmap and so on. The benefits are three-fold. One - For teams to use Threat Modeling as a first-class citizen(with code). Facilitating Iterative and Updated Threat Models and Security Test Cases, as the product evolves (not a stationary document). Two - For Threat Modeling to become actionable. Product Teams can use this Framework to compose “Recipes” where User Stories (Functionality) leads to Abuser Stories (Threat Profiles) which lead to Threat Models (scenarios), that are used to create Security Test Cases (which kick off certain tools) based on the Recipes written for the Test Cases. Three - This approach leads to a convergence of Threat Modeling and Security Testing, allowing teams to improve both security testing and threat modeling based on results produced through this framework. ]]>
Threat Modeling is critical for Product Engineering Team. Yet, even in the rare event that it’s performed, its performed without actionable outputs emerging from the exercise. It is relegated to the status of what a “Policy/Best Practice Document”, which it shouldn’t be. I believe that Threat Models are playbooks of Product Security Engineering. I feel that the best way to do threat modeling is to integrate it into the Software Development Lifecycle (SDL). In addition, I believe that Threat Models should produce actionable outputs that can be acted up on by various teams within the organization. To address this lacuna, I have developed “Automaton” - An Open Source “Threat Modeling as Code” framework, that allows product teams to capture User Stories, Abuser Stories, Threat Models and Security Test Cases in YAML Files (like Ansible). With the help of Test Automation Frameworks (in this case, Robot Framework) Automaton allows the product engineering team to not only capture Threat Models as code, but also trigger specific security test cases with tools like OWASP ZAP, BurpSuite, WFuzz, Sublist3r, Nmap and so on. The benefits are three-fold. One - For teams to use Threat Modeling as a first-class citizen(with code). Facilitating Iterative and Updated Threat Models and Security Test Cases, as the product evolves (not a stationary document). Two - For Threat Modeling to become actionable. Product Teams can use this Framework to compose “Recipes” where User Stories (Functionality) leads to Abuser Stories (Threat Profiles) which lead to Threat Models (scenarios), that are used to create Security Test Cases (which kick off certain tools) based on the Recipes written for the Test Cases. Three - This approach leads to a convergence of Threat Modeling and Security Testing, allowing teams to improve both security testing and threat modeling based on results produced through this framework. ]]> Fri, 12 Oct 2018 03:52:44 GMT /slideshow/threatmodelingascode-threatplaybook-appsecusa-2018-presentation/119170907 abhaybhargav@slideshare.net(abhaybhargav) Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation abhaybhargav Threat Modeling is critical for Product Engineering Team. Yet, even in the rare event that it’s performed, its performed without actionable outputs emerging from the exercise. It is relegated to the status of what a “Policy/Best Practice Document”, which it shouldn’t be. I believe that Threat Models are playbooks of Product Security Engineering. I feel that the best way to do threat modeling is to integrate it into the Software Development Lifecycle (SDL). In addition, I believe that Threat Models should produce actionable outputs that can be acted up on by various teams within the organization. To address this lacuna, I have developed “Automaton” - An Open Source “Threat Modeling as Code” framework, that allows product teams to capture User Stories, Abuser Stories, Threat Models and Security Test Cases in YAML Files (like Ansible). With the help of Test Automation Frameworks (in this case, Robot Framework) Automaton allows the product engineering team to not only capture Threat Models as code, but also trigger specific security test cases with tools like OWASP ZAP, BurpSuite, WFuzz, Sublist3r, Nmap and so on. The benefits are three-fold. One - For teams to use Threat Modeling as a first-class citizen(with code). Facilitating Iterative and Updated Threat Models and Security Test Cases, as the product evolves (not a stationary document). Two - For Threat Modeling to become actionable. Product Teams can use this Framework to compose “Recipes” where User Stories (Functionality) leads to Abuser Stories (Threat Profiles) which lead to Threat Models (scenarios), that are used to create Security Test Cases (which kick off certain tools) based on the Recipes written for the Test Cases. Three - This approach leads to a convergence of Threat Modeling and Security Testing, allowing teams to improve both security testing and threat modeling based on results produced through this framework. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/appsecusa2018abhaybhargav-181012035244-thumbnail.jpg?width=120&height=120&fit=bounds" /> Threat Modeling is critical for Product Engineering Team. Yet, even in the rare event that it’s performed, its performed without actionable outputs emerging from the exercise. It is relegated to the status of what a “Policy/Best Practice Document”, which it shouldn’t be. I believe that Threat Models are playbooks of Product Security Engineering. I feel that the best way to do threat modeling is to integrate it into the Software Development Lifecycle (SDL). In addition, I believe that Threat Models should produce actionable outputs that can be acted up on by various teams within the organization. To address this lacuna, I have developed “Automaton” - An Open Source “Threat Modeling as Code” framework, that allows product teams to capture User Stories, Abuser Stories, Threat Models and Security Test Cases in YAML Files (like Ansible). With the help of Test Automation Frameworks (in this case, Robot Framework) Automaton allows the product engineering team to not only capture Threat Models as code, but also trigger specific security test cases with tools like OWASP ZAP, BurpSuite, WFuzz, Sublist3r, Nmap and so on. The benefits are three-fold. One - For teams to use Threat Modeling as a first-class citizen(with code). Facilitating Iterative and Updated Threat Models and Security Test Cases, as the product evolves (not a stationary document). Two - For Threat Modeling to become actionable. Product Teams can use this Framework to compose “Recipes” where User Stories (Functionality) leads to Abuser Stories (Threat Profiles) which lead to Threat Models (scenarios), that are used to create Security Test Cases (which kick off certain tools) based on the Recipes written for the Test Cases. Three - This approach leads to a convergence of Threat Modeling and Security Testing, allowing teams to improve both security testing and threat modeling based on results produced through this framework.

Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation from Abhay Bhargav

]]> 1399 3 https://cdn.slidesharecdn.com/ss_thumbnails/appsecusa2018abhaybhargav-181012035244-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 Merging Security with DevOps - An AppSec Perspective /slideshow/merging-security-with-devops-an-appsec-perspective/79545025 webinarmergingsecuritydevopsv1-170908025846
This is from we45's webinar on 7th September 2017 focused on DevSecOps, especially around Automating and Customizing DAST with OWASP ZAP]]>
This is from we45's webinar on 7th September 2017 focused on DevSecOps, especially around Automating and Customizing DAST with OWASP ZAP]]> Fri, 08 Sep 2017 02:58:46 GMT /slideshow/merging-security-with-devops-an-appsec-perspective/79545025 abhaybhargav@slideshare.net(abhaybhargav) Merging Security with DevOps - An AppSec Perspective abhaybhargav This is from we45's webinar on 7th September 2017 focused on DevSecOps, especially around Automating and Customizing DAST with OWASP ZAP <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/webinarmergingsecuritydevopsv1-170908025846-thumbnail.jpg?width=120&height=120&fit=bounds" /> This is from we45's webinar on 7th September 2017 focused on DevSecOps, especially around Automating and Customizing DAST with OWASP ZAP

Merging Security with DevOps - An AppSec Perspective from Abhay Bhargav

]]> 948 3 https://cdn.slidesharecdn.com/ss_thumbnails/webinarmergingsecuritydevopsv1-170908025846-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 we45 DEFCON Workshop - Building AppSec Automation with Python /slideshow/we45-defcon-workshop-building-appsec-automation-with-python/78371451 defconpresov2fin-170729154643
Abhay Bhargav's DEFCON 25 Workshop on using Python to build AppSec Automation for integration with CI/CD Pipelines]]>
Abhay Bhargav's DEFCON 25 Workshop on using Python to build AppSec Automation for integration with CI/CD Pipelines]]> Sat, 29 Jul 2017 15:46:43 GMT /slideshow/we45-defcon-workshop-building-appsec-automation-with-python/78371451 abhaybhargav@slideshare.net(abhaybhargav) we45 DEFCON Workshop - Building AppSec Automation with Python abhaybhargav Abhay Bhargav's DEFCON 25 Workshop on using Python to build AppSec Automation for integration with CI/CD Pipelines <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/defconpresov2fin-170729154643-thumbnail.jpg?width=120&height=120&fit=bounds" /> Abhay Bhargav's DEFCON 25 Workshop on using Python to build AppSec Automation for integration with CI/CD Pipelines

we45 DEFCON Workshop - Building AppSec Automation with Python from Abhay Bhargav

]]> 1173 4 https://cdn.slidesharecdn.com/ss_thumbnails/defconpresov2fin-170729154643-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 OWASP AppSec EU - SecDevOps, a view from the trenches - Abhay Bhargav /slideshow/owasp-appsec-eu-secdevops-a-view-from-the-trenches-abhay-bhargav/64295695 owaspappseceuabhaybhargavv11-160722205616
s its biggest bottleneck and security is becoming the most pervasive bottleneck in most DevOps practices. Teams are unable to come up with security practices that integrate into the DevOps lifecycle and ensure continuous and smooth delivery of applications to customers. In fact, security failures in DevOps amplify security flaws in production as they are delivered at scale. If DevOps should not be at odds with security, then we must find ways to achieve the following on priority: - Integrate effective threat modeling into Agile development practices - Introduce Security Automation into Continuous Integration - Integrate Security Automation into Continuous Deployment While there are other elements like SAST and Monitoring that are important to SecDevOps, my talk will essentially focus on these three elements with a higher level of focus on Security Automation. In my talk, I will explore the following, with reference to the topic: - The talk will be replete with anecdotes from personal consulting and penetration testing experiences. - I will briefly discuss Threat Modeling and its impact on DevOps. I will use examples to demonstrate practical ways that one can use threat modeling effectively to break down obstacles and create security automation that reduces the security bottleneck in the later stages of the DevOps cycle. - I firmly believe that Automated Web Vulnerability Assessment (using scanners) no matter how tuned, can only produce 30-40% of the actual results as opposed to a manual application penetration test. I find that scanning tools fail to identify most vulnerabilities with modern Web Services (REST. I will discuss examples and demonstrate how one can leverage automated vulnerability scanners (like ZAP, through its Python API) and simulate manual testing using a custom security automation suite. In Application Penetration Testing, its impossible to have a one size-fits all, but there’s no reason why we can’t deliver custom security automation to simulate most of the manual penetration testing to combine them into a custom security automation suite that integrates with CI tools like Jenkins and Travis. I intend to demonstrate the use a custom security test suite (written in Python that integrates with Jenkins), against an intentionally vulnerable e-commerce app. - My talk will also detail automation to identify vulnerabilities in software libraries and components, integrated with CI tools. - Finally, I will (with the use of examples and demos) explain how one can use “Infrastructure as Code” practice to perform pre and post deployment security checks, using tools like Chef, Puppet and Ansible.]]>
s its biggest bottleneck and security is becoming the most pervasive bottleneck in most DevOps practices. Teams are unable to come up with security practices that integrate into the DevOps lifecycle and ensure continuous and smooth delivery of applications to customers. In fact, security failures in DevOps amplify security flaws in production as they are delivered at scale. If DevOps should not be at odds with security, then we must find ways to achieve the following on priority: - Integrate effective threat modeling into Agile development practices - Introduce Security Automation into Continuous Integration - Integrate Security Automation into Continuous Deployment While there are other elements like SAST and Monitoring that are important to SecDevOps, my talk will essentially focus on these three elements with a higher level of focus on Security Automation. In my talk, I will explore the following, with reference to the topic: - The talk will be replete with anecdotes from personal consulting and penetration testing experiences. - I will briefly discuss Threat Modeling and its impact on DevOps. I will use examples to demonstrate practical ways that one can use threat modeling effectively to break down obstacles and create security automation that reduces the security bottleneck in the later stages of the DevOps cycle. - I firmly believe that Automated Web Vulnerability Assessment (using scanners) no matter how tuned, can only produce 30-40% of the actual results as opposed to a manual application penetration test. I find that scanning tools fail to identify most vulnerabilities with modern Web Services (REST. I will discuss examples and demonstrate how one can leverage automated vulnerability scanners (like ZAP, through its Python API) and simulate manual testing using a custom security automation suite. In Application Penetration Testing, its impossible to have a one size-fits all, but there’s no reason why we can’t deliver custom security automation to simulate most of the manual penetration testing to combine them into a custom security automation suite that integrates with CI tools like Jenkins and Travis. I intend to demonstrate the use a custom security test suite (written in Python that integrates with Jenkins), against an intentionally vulnerable e-commerce app. - My talk will also detail automation to identify vulnerabilities in software libraries and components, integrated with CI tools. - Finally, I will (with the use of examples and demos) explain how one can use “Infrastructure as Code” practice to perform pre and post deployment security checks, using tools like Chef, Puppet and Ansible.]]> Fri, 22 Jul 2016 20:56:16 GMT /slideshow/owasp-appsec-eu-secdevops-a-view-from-the-trenches-abhay-bhargav/64295695 abhaybhargav@slideshare.net(abhaybhargav) OWASP AppSec EU - SecDevOps, a view from the trenches - Abhay Bhargav abhaybhargav s its biggest bottleneck and security is becoming the most pervasive bottleneck in most DevOps practices. Teams are unable to come up with security practices that integrate into the DevOps lifecycle and ensure continuous and smooth delivery of applications to customers. In fact, security failures in DevOps amplify security flaws in production as they are delivered at scale. If DevOps should not be at odds with security, then we must find ways to achieve the following on priority: - Integrate effective threat modeling into Agile development practices - Introduce Security Automation into Continuous Integration - Integrate Security Automation into Continuous Deployment While there are other elements like SAST and Monitoring that are important to SecDevOps, my talk will essentially focus on these three elements with a higher level of focus on Security Automation. In my talk, I will explore the following, with reference to the topic: - The talk will be replete with anecdotes from personal consulting and penetration testing experiences. - I will briefly discuss Threat Modeling and its impact on DevOps. I will use examples to demonstrate practical ways that one can use threat modeling effectively to break down obstacles and create security automation that reduces the security bottleneck in the later stages of the DevOps cycle. - I firmly believe that Automated Web Vulnerability Assessment (using scanners) no matter how tuned, can only produce 30-40% of the actual results as opposed to a manual application penetration test. I find that scanning tools fail to identify most vulnerabilities with modern Web Services (REST. I will discuss examples and demonstrate how one can leverage automated vulnerability scanners (like ZAP, through its Python API) and simulate manual testing using a custom security automation suite. In Application Penetration Testing, its impossible to have a one size-fits all, but there’s no reason why we can’t deliver custom security automation to simulate most of the manual penetration testing to combine them into a custom security automation suite that integrates with CI tools like Jenkins and Travis. I intend to demonstrate the use a custom security test suite (written in Python that integrates with Jenkins), against an intentionally vulnerable e-commerce app. - My talk will also detail automation to identify vulnerabilities in software libraries and components, integrated with CI tools. - Finally, I will (with the use of examples and demos) explain how one can use “Infrastructure as Code” practice to perform pre and post deployment security checks, using tools like Chef, Puppet and Ansible. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/owaspappseceuabhaybhargavv11-160722205616-thumbnail.jpg?width=120&height=120&fit=bounds" /> s its biggest bottleneck and security is becoming the most pervasive bottleneck in most DevOps practices. Teams are unable to come up with security practices that integrate into the DevOps lifecycle and ensure continuous and smooth delivery of applications to customers. In fact, security failures in DevOps amplify security flaws in production as they are delivered at scale. If DevOps should not be at odds with security, then we must find ways to achieve the following on priority: - Integrate effective threat modeling into Agile development practices - Introduce Security Automation into Continuous Integration - Integrate Security Automation into Continuous Deployment While there are other elements like SAST and Monitoring that are important to SecDevOps, my talk will essentially focus on these three elements with a higher level of focus on Security Automation. In my talk, I will explore the following, with reference to the topic: - The talk will be replete with anecdotes from personal consulting and penetration testing experiences. - I will briefly discuss Threat Modeling and its impact on DevOps. I will use examples to demonstrate practical ways that one can use threat modeling effectively to break down obstacles and create security automation that reduces the security bottleneck in the later stages of the DevOps cycle. - I firmly believe that Automated Web Vulnerability Assessment (using scanners) no matter how tuned, can only produce 30-40% of the actual results as opposed to a manual application penetration test. I find that scanning tools fail to identify most vulnerabilities with modern Web Services (REST. I will discuss examples and demonstrate how one can leverage automated vulnerability scanners (like ZAP, through its Python API) and simulate manual testing using a custom security automation suite. In Application Penetration Testing, its impossible to have a one size-fits all, but there’s no reason why we can’t deliver custom security automation to simulate most of the manual penetration testing to combine them into a custom security automation suite that integrates with CI tools like Jenkins and Travis. I intend to demonstrate the use a custom security test suite (written in Python that integrates with Jenkins), against an intentionally vulnerable e-commerce app. - My talk will also detail automation to identify vulnerabilities in software libraries and components, integrated with CI tools. - Finally, I will (with the use of examples and demos) explain how one can use “Infrastructure as Code” practice to perform pre and post deployment security checks, using tools like Chef, Puppet and Ansible.

OWASP AppSec EU - SecDevOps, a view from the trenches - Abhay Bhargav from Abhay Bhargav

]]> 2579 3 https://cdn.slidesharecdn.com/ss_thumbnails/owaspappseceuabhaybhargavv11-160722205616-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 we45 - Infrastructure Penetration Testing with LeanBeast Case Study /slideshow/we45-infrastructure-penetration-testing-with-leanbeast-case-study/56940704 we45infrastructuresecuritycasefile-160112064613
The Leanbeast – is we45’s hybrid infrastructure and network security assessment platform that leverages automation and skill in delivering powerful and repeatable security assessments to enterprises. Leanbeast is replete with the relevant tools and we45’s custom penetration scripts that deliver unmatched network infrastructure security assessments. Security assessments performed through Leanbeast can be completely managed and controlled remotely thereby giving organizations the leverage of reduced (operational) costs. Leanbeast is NOT an automated vulnerability scanner. The infusion of a hybrid assessment framework with custom scripts and tools results in Leanbeast as a full-fledged Penetration Testing platform. ]]>
The Leanbeast – is we45’s hybrid infrastructure and network security assessment platform that leverages automation and skill in delivering powerful and repeatable security assessments to enterprises. Leanbeast is replete with the relevant tools and we45’s custom penetration scripts that deliver unmatched network infrastructure security assessments. Security assessments performed through Leanbeast can be completely managed and controlled remotely thereby giving organizations the leverage of reduced (operational) costs. Leanbeast is NOT an automated vulnerability scanner. The infusion of a hybrid assessment framework with custom scripts and tools results in Leanbeast as a full-fledged Penetration Testing platform. ]]> Tue, 12 Jan 2016 06:46:13 GMT /slideshow/we45-infrastructure-penetration-testing-with-leanbeast-case-study/56940704 abhaybhargav@slideshare.net(abhaybhargav) we45 - Infrastructure Penetration Testing with LeanBeast Case Study abhaybhargav The Leanbeast – is we45’s hybrid infrastructure and network security assessment platform that leverages automation and skill in delivering powerful and repeatable security assessments to enterprises. Leanbeast is replete with the relevant tools and we45’s custom penetration scripts that deliver unmatched network infrastructure security assessments. Security assessments performed through Leanbeast can be completely managed and controlled remotely thereby giving organizations the leverage of reduced (operational) costs. Leanbeast is NOT an automated vulnerability scanner. The infusion of a hybrid assessment framework with custom scripts and tools results in Leanbeast as a full-fledged Penetration Testing platform. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/we45infrastructuresecuritycasefile-160112064613-thumbnail.jpg?width=120&height=120&fit=bounds" /> The Leanbeast – is we45’s hybrid infrastructure and network security assessment platform that leverages automation and skill in delivering powerful and repeatable security assessments to enterprises. Leanbeast is replete with the relevant tools and we45’s custom penetration scripts that deliver unmatched network infrastructure security assessments. Security assessments performed through Leanbeast can be completely managed and controlled remotely thereby giving organizations the leverage of reduced (operational) costs. Leanbeast is NOT an automated vulnerability scanner. The infusion of a hybrid assessment framework with custom scripts and tools results in Leanbeast as a full-fledged Penetration Testing platform.

we45 - Infrastructure Penetration Testing with LeanBeast Case Study from Abhay Bhargav

]]> 987 8 https://cdn.slidesharecdn.com/ss_thumbnails/we45infrastructuresecuritycasefile-160112064613-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 we45 - SecDevOps Concept Presentation /slideshow/we45-secdevops-concept-presentation/56940534 we45secdevopsapproachv1-160112064006
we45’s SecDevOps and Security Automation Framework (2SAF) aims at decreasing mean time to product deployment with reduced operational resources – with the inclusion of relevant custom product security controls. The 2SAF enables engineering teams to implement a customized automated and threat modeled penetration testing model for every release of the produce lifecycle. Our powerful Review – Train – Study model has enabled engineering and DevOps teams to implement 2SAF within weeks to a fully operational and measurable working framework.]]>
we45’s SecDevOps and Security Automation Framework (2SAF) aims at decreasing mean time to product deployment with reduced operational resources – with the inclusion of relevant custom product security controls. The 2SAF enables engineering teams to implement a customized automated and threat modeled penetration testing model for every release of the produce lifecycle. Our powerful Review – Train – Study model has enabled engineering and DevOps teams to implement 2SAF within weeks to a fully operational and measurable working framework.]]> Tue, 12 Jan 2016 06:40:06 GMT /slideshow/we45-secdevops-concept-presentation/56940534 abhaybhargav@slideshare.net(abhaybhargav) we45 - SecDevOps Concept Presentation abhaybhargav we45’s SecDevOps and Security Automation Framework (2SAF) aims at decreasing mean time to product deployment with reduced operational resources – with the inclusion of relevant custom product security controls. The 2SAF enables engineering teams to implement a customized automated and threat modeled penetration testing model for every release of the produce lifecycle. Our powerful Review – Train – Study model has enabled engineering and DevOps teams to implement 2SAF within weeks to a fully operational and measurable working framework. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/we45secdevopsapproachv1-160112064006-thumbnail.jpg?width=120&height=120&fit=bounds" /> we45’s SecDevOps and Security Automation Framework (2SAF) aims at decreasing mean time to product deployment with reduced operational resources – with the inclusion of relevant custom product security controls. The 2SAF enables engineering teams to implement a customized automated and threat modeled penetration testing model for every release of the produce lifecycle. Our powerful Review – Train – Study model has enabled engineering and DevOps teams to implement 2SAF within weeks to a fully operational and measurable working framework.

we45 - SecDevOps Concept Presentation from Abhay Bhargav

]]> 1190 5 https://cdn.slidesharecdn.com/ss_thumbnails/we45secdevopsapproachv1-160112064006-thumbnail.jpg?width=120&height=120&fit=bounds presentation Black http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 we45 SecDevOps Presentation - ISACA Chennai /slideshow/we45-secdevops-presentation-isaca-chennai/56870625 secdevops-isaca-chennaiv1-160110081815
Abhay Bhargav, the CTO of we45 spoke to ISACA Chennai on how DevOps security practices must be leveraged to secure Hyper-Scale Cloud Applications. ]]>
Abhay Bhargav, the CTO of we45 spoke to ISACA Chennai on how DevOps security practices must be leveraged to secure Hyper-Scale Cloud Applications. ]]> Sun, 10 Jan 2016 08:18:15 GMT /slideshow/we45-secdevops-presentation-isaca-chennai/56870625 abhaybhargav@slideshare.net(abhaybhargav) we45 SecDevOps Presentation - ISACA Chennai abhaybhargav Abhay Bhargav, the CTO of we45 spoke to ISACA Chennai on how DevOps security practices must be leveraged to secure Hyper-Scale Cloud Applications. <img style="border:1px solid #C3E6D8;float:right;" alt="" src="https://cdn.slidesharecdn.com/ss_thumbnails/secdevops-isaca-chennaiv1-160110081815-thumbnail.jpg?width=120&height=120&fit=bounds" /> Abhay Bhargav, the CTO of we45 spoke to ISACA Chennai on how DevOps security practices must be leveraged to secure Hyper-Scale Cloud Applications.

we45 SecDevOps Presentation - ISACA Chennai from Abhay Bhargav

]]> 1543 4 https://cdn.slidesharecdn.com/ss_thumbnails/secdevops-isaca-chennaiv1-160110081815-thumbnail.jpg?width=120&height=120&fit=bounds presentation 000000 http://activitystrea.ms/schema/1.0/post

http://activitystrea.ms/schema/1.0/posted

0 https://cdn.slidesharecdn.com/profile-photo-abhaybhargav-48x48.jpg?cb=1634817095 Abhay Bhargav is the CTO of the we45 Group, an Information Security Solutions Company. He has extensive experience with Information Security and Compliance. He performs security assessments for enterprises in various domains like banking, software development, retail, telecom and legal. He is also the co-author of “Secure Java for Web Application Development” to be published by CRC Press, New York. He specializes in Web Application Security and performs security testing and consulting engagements for a wide array of enterprises and governmental/quasi-governmental entities. He also possesses vulnerability assessment and penetration testing experience. He has been involved in several suc http://www.we45.com https://cdn.slidesharecdn.com/ss_thumbnails/abhaybhargavappseccalislsgql-190125225910-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/an-attackers-view-of-serverless-and-graphql-apps-abhay-bhargav-appsec-california-2019/129289800 An Attacker's View of ... https://cdn.slidesharecdn.com/ss_thumbnails/appsecusa2018abhaybhargav-181012035244-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/threatmodelingascode-threatplaybook-appsecusa-2018-presentation/119170907 Threat-Modeling-as-Cod... https://cdn.slidesharecdn.com/ss_thumbnails/webinarmergingsecuritydevopsv1-170908025846-thumbnail.jpg?width=320&height=320&fit=bounds slideshow/merging-security-with-devops-an-appsec-perspective/79545025 Merging Security with ...