OWASP - User contributions [en]

OWASP DHS SWA Day 2010 OWASP WTE

2010-10-22T20:59:00Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Web Testing Environment, previously the OWASP Live CD.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Matt_Tesauro_2010-09_OWASP_DHS_SWA_Day_-_WTE.ppt | Download the presentation]]

== The speaker ==

[http://www.owasp.org/index.php/User:Mtesauro Matt Tesauro's Bio]

== Notes ==
;[[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]]

The OWASP Live CD is an educational supplement project containing tutorials, challenges and videos detailing the use of tools contained within the OWASP LiveCD - LabRat. This project was sponsored by [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]] and [http://www.securitydistro.com/ Security Distro] (Assessment Criteria v1.0)

It’s hard to be a tester if you have never been a developer. The goal of the CD was originally to create a ready-made environment in which to perform testing. The CD showcases great tools and contains not only OWASP tools.

The design goals include being easy to keep users up to date while being easy to update.There were gaps between the tools and the testing guides. The goal is to keep them aligned.

[http://www.appseclive.org/ The OWASP Web Testing Environment (WTE)] is the new name of the DVD which includes 26 significant tools. WTE also includes Firefox security add-ons, OWASP documents, a Top 10 risks list, VM software, and many other. WTE is also used as an education tool. The Webgoat tool is already being used for training classes.

WTE consists of more tools focused on developing instead of testing focused; there are more tools available via a repository for packages. Each tool will now automatically install dependent tools. WTE now runs on Ubuntu and each tool has its own Debian package. You can mix and match packages for only what you need to use. Some new features to be added in future versions are virtual installs, USB bootable install, customized versions of WTE via a la carte builds.

--[[User:Walter Houser|Walter Houser]] 22:18, 5 October 2010 (UTC)
[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T22:19:44Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

[http://www.owasp.org/index.php/User:Jason_Li Jason Li] is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The [http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Project] lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Li reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: [http://www.owasp.org/index.php/Category:OWASP_DirBuster_Project OWASP DirBuster] can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)]. APP6130 Systems Monitoring would be met by the [http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]. APP5100 Fuzz Testing can be met by the [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] and the [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project OWASP WSFuzzer Project].

--[[User:Walter Houser|Walter Houser]] 22:19, 5 October 2010 (UTC)
[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 ESAPI

2010-10-05T22:19:14Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Enterprise Security API, or ESAPI

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_ESAPI.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

==Notes ==
;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI is a free and open collection of all the security methods that a developer needs to build a secure web application. (Assessment Criteria v1.0)

Several years ago, Williams was asked to review applications supported by a development shop. He discovered that every developer was reinventing code, and doing it incorrectly, sometimes multiple distinct solutions for the same problems. We looked at the application vulnerabilities. Scanning is valuable but it will not distinguish why applications are broken. His findings were:

* 35% of vulnerabilities had no controls.
* 30 percent of application controls were broken and ineffective.
* 20 percent were ignored. This is harder than just giving developers the controls. So we need to make the controls easier to use.
* 15 percent of controls were not used correctly. Ease of use is necessary for this case as well.

'''Security Controls are Hard'''

There are 1.6 quadrillion or 785 ways to encode a character in canonical form. We need to make it simpler for the developers to use the controls. We want to pull the controls out of the code and put them in a application security control library for the developers to use. We want to manage security instead of insecurity. Controls instead of threats. Patterns instead of vulnerabilities. If you manage vulnerabilities and patches, the problems quickly become unmanageable. If you manage assurance, you can get ahead of the vulnerabilities by stamping large classes of vulnerabilities at a time. We identified 100 methods with a common application programming interface (API).

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development. You cant just download ESAPI and use it out of the wrapper. Each organization needs to create its own security library.

Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design:
* There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls.
* There is a reference implementation for each security control. The logic is not organization specific and the logic is not application specific. An example: string based input validation.
* There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

There are ESAPI tools for Java, .NET, PHP, Cold Fusion, ASP, Python, AJAX (Javascript on the client side), Ruby, C, and Salesforce.com. Also, with ESAPI each application could have its own web application firewall. The WAF can implement a virtual patch, check session states, user authentication, and other application characteristics.

When an attack comes out, we can review our code and make patches so that all developers using ESAPI will benefit. Taking an assurance case perspective, we built almost a thousand test cases. We have tests for canonicalization, output escaping. Also we can establish user identification and access control. We have run Fortify, AppScan (Once Labs), and PMD. The output from FindBugs is interesting. Do all my Sturts action make sequential calls to authentication and logger?

Why invest in application security? There is a business and ROI. Also appsec enables innovation, it allows organizations to do things they can’t do today.

Q. What is the training requirement?
A. It is difficult to teach developers to teach all about application security. It is far easier to teach an API in their own language. ESAPI simplifies the learning process. You can cover ESPAI in a day for a decent Java developer.

See the [http://www.csirt.org/color_%20books/C-TR-32-92.pdf The Design and Evaluation of INFOSEC Systems: The Computer Security Contribution ] in the rainbow series by Mario Tinto

In order for the firewall to determine if the request is malevolent. The application understands the business rules whereas the firewall does not. ESAPI makes the code a lot simpler and easier to figure out what the policy being enforced.

--[[User:Walter Houser|Walter Houser]] 22:19, 5 October 2010 (UTC)
[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OWASP WTE

2010-10-05T22:18:36Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Web Testing Environment, previously the OWASP Live CD.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Matt_Tesauro_2010-09_OWASP_DHS_SWA_Day_-_WTE.ppt | Download the presentation]]

== The speaker ==

[http://www.owasp.org/index.php/User:Mtesauro Matt Tesauro's Bio]

== Notes ==
;[[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]]

The OWASP Live CD is an educational supplement project containing tutorials, challenges and videos detailing the use of tools contained within the OWASP LiveCD - LabRat. This project was sponsored by [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]] and [http://www.securitydistro.com/ Security Distro] (Assessment Criteria v1.0)

It’s hard to be a tester if you have never been a developer. The goal of the CD was originally to create a ready-made environment in which to perform testing. The CD showcases great tools and contains not only OWASP tools.

The design goals include being easy to keep users up to date while being easy to update.There were gaps between the tools and the testing guides. The goal is to keep them aligned.

The OWASP Web Testing Environment (WTE) is the new name of the DVD which includes 26 significant tools. WTE also includes Firefox security add-ons, OWASP documents, a Top 10 risks list, VM software, and many other. WTE is also used as an education tool. The Webgoat tool is already being used for training classes.

WTE consists of more tools focused on developing instead of testing focused; there are more tools available via a repository for packages. Each tool will now automatically install dependent tools. WTE now runs on Ubuntu and each tool has its own Debian package. You can mix and match packages for only what you need to use. Some new features to be added in future versions are virtual installs, USB bootable install, customized versions of WTE via a la carte builds.

--[[User:Walter Houser|Walter Houser]] 22:18, 5 October 2010 (UTC)
[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T22:18:08Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the [http://www.opensamm.org/ OSAMM.ORG ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

--[[User:Walter Houser|Walter Houser]] 22:17, 5 October 2010 (UTC)
[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T22:17:46Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the [http://www.opensamm.org/ OSAMM.ORG ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.
--[[User:Walter Houser|Walter Houser]] 22:17, 5 October 2010 (UTC)
[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T20:45:30Z

Walter Houser:

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:23:09Z

Walter Houser:

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:20:37Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org/[[Media: ]] OSAMM.ORG ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:19:25Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org/ OSAMM ORG ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:18:38Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org/ <&nbsp> opensamm.org ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:18:03Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org/ opensamm.org ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:17:43Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org/ www.opensamm.org ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:17:19Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org www.opensamm.org ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:16:59Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org www.opensamm.org ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:16:11Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org ] web site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T20:14:57Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization. Anyone can provide feedback on OSAMM at the[http://www.opensamm.org ] we site. SAMM has Creative Commons rights management.

OSAMM is used as a measuring stick against an organization’s security practices and functions. The OSAMM maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

OSAMM divides the SDLC into the governance, construction, verification, and deployment business functions, each consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA. See [https://buildsecurityin.us-cert.gov/swa/proself_assm.html Software Assurance (SwA) Self-Assessment
] where the SwA Processes and Practices Working Group has synthesized the contributions of leading government and industry experts (including OSAMM) into a set of high-level goals and supporting practices.

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:58:43Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The [http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top Ten Project] lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Li reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: [http://www.owasp.org/index.php/Category:OWASP_DirBuster_Project OWASP DirBuster] can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)]. APP6130 Systems Monitoring would be met by the [http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]. APP5100 Fuzz Testing can be met by the [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] and the [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project OWASP WSFuzzer Project].

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:57:14Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Li reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: [http://www.owasp.org/index.php/Category:OWASP_DirBuster_Project OWASP DirBuster] can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP Application Security Verification Standard (ASVS)]. APP6130 Systems Monitoring would be met by the [http://www.owasp.org/index.php/Category:OWASP_AppSensor_Project OWASP AppSensor Project]. APP5100 Fuzz Testing can be met by the [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] and the [http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project OWASP WSFuzzer Project].

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:54:06Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by the [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] and the [[http://www.owasp.org/index.php/Category:OWASP_WSFuzzer_Project OWASP WSFuzzer Project]].

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:53:26Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by the [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] and the [[OWASP_WSFuzzer_Project]].
OWASP_WSFuzzer_Project

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:51:09Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by the [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] and the [[OWASP WSFuzzer Project|OWASP WSFuzzer Project]]
.

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:49:20Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by [[ OWASP JBroFuzz|OWASP JBroFuzz Project]] [[ OWASP WSFuzzer|OWASP WSFuzzer Project]] and WSFuzzer.

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:48:04Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by JBroFuzz and WSFuzzer.
[[Category:OWASP JBroFuzz|OWASP JBroFuzz Project]]

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:46:40Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by [[:Category:OWASP JBroFuzz|OWASP JBroFuzz Project]]
and WSFuzzer.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OWASP WTE

2010-10-05T19:42:24Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Web Testing Environment, previously the OWASP Live CD.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Matt_Tesauro_2010-09_OWASP_DHS_SWA_Day_-_WTE.ppt | Download the presentation]]

== The speaker ==

[http://www.owasp.org/index.php/User:Mtesauro Matt Tesauro's Bio]

== Notes ==
;[[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]]

The OWASP Live CD is an educational supplement project containing tutorials, challenges and videos detailing the use of tools contained within the OWASP LiveCD - LabRat. This project was sponsored by [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]] and [http://www.securitydistro.com/ Security Distro] (Assessment Criteria v1.0)

It’s hard to be a tester if you have never been a developer. The goal of the CD was originally to create a ready-made environment in which to perform testing. The CD showcases great tools and contains not only OWASP tools.

The design goals include being easy to keep users up to date while being easy to update.There were gaps between the tools and the testing guides. The goal is to keep them aligned.

The OWASP Web Testing Environment (WTE) is the new name of the DVD which includes 26 significant tools. WTE also includes Firefox security add-ons, OWASP documents, a Top 10 risks list, VM software, and many other. WTE is also used as an education tool. The Webgoat tool is already being used for training classes.

WTE consists of more tools focused on developing instead of testing focused; there are more tools available via a repository for packages. Each tool will now automatically install dependent tools. WTE now runs on Ubuntu and each tool has its own Debian package. You can mix and match packages for only what you need to use. Some new features to be added in future versions are virtual installs, USB bootable install, customized versions of WTE via a la carte builds.

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:39:19Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “[http://iase.disa.mil/stigs/faq.html#15 gold disk]” for the ASD STIG. However, the [[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]] could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by JBroFuzz and WSFuzzer.

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:36:35Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/downloads/zip/unclassified_application_security_development_stig_v3r1.zip Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “gold disk” for the ASD STIG. However, the OWASP Live CD could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by JBroFuzz and WSFuzzer.

[[Category:OWASP_Conference_Presentations]]

OWASP in Action: Tools for the DISA ASD STIG

2010-10-05T19:35:34Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]In April 2010, the Defense Information Systems Agency (DISA) released Version 3 of its Application Security and Development (ASD) Security Technical Implementation Guide (STIG). The ASD STIG is a series of application security requirements that apply to "all DoD developed, architected, and administered applications and systems connected to DoD networks." This presentation talks about the various [[Category:OWASP Project| OWASP Projects]] that can be used to help fulfill these requirements. This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:OWASPSoftwareAssuranceDay2010.ppt | Download the presentation]]

== The speaker ==

Jason Li is a Principal Consultant for Aspect Security where he has performed numerous ASD STIG validation tests of a variety of applications. In addition, he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving as Co-Chair of the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

== Notes ==

Defense Information Systems Agency (DISA) provides Security Implementation Technical Guides (STIGs) to cover the gamut of systems dev elopement. The [http://iase.disa.mil/stigs/stig/application_security_and_development_stig_v2r1_final_20080724.pdf Application Security and Development (ASD) STIG] first issued in 2006 and the most recent issuance came out in April 2010. This STIG applies to all DOD developed, architected, and administered applications. There are a 157 different STIG rules, some are very broad, others very specific, and some are complex. It is easy to get lost in the weeds. Some are harder to test than others. There are procedural, configuration, and standards requirements. OWASP is explicitly called out as a resource in the ASD STIG checklist; see the OWASP documentation projects and they are free. The OWASP top ten lines up well with the ASP STIG; there are 33 Category One STIG flaws most of which in the top 10.

Jason reviewed the STIG requirements and related OWASP tools and methods. There is no “gold disk” for the ASD STIG. However, the OWASP Live CD could be used if some one were to contribute a mapping of the tools with the STIG. Some of the requirements Jason reviewed include: OWASP DirBuster can in part address APP3620 Information Disclosure. APP5080 Code Review is covered by the OWASP Application Security Verification Standard (ASVS). APP6130 Systems Monitoring would be met by AppSensor Project. APP5100 Fuzz Testing can be met by JBroFuzz and WSFuzzer.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 ESAPI

2010-10-05T19:31:17Z

Walter Houser:

OWASP DHS SWA Day 2010 ESAPI

2010-10-05T19:30:43Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Enterprise Security API, or ESAPI

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_ESAPI.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

==Notes ==
;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI is a free and open collection of all the security methods that a developer needs to build a secure web application. (Assessment Criteria v1.0)

Several years ago, Williams was asked to review applications supported by a development shop. He discovered that every developer was reinventing code, and doing it incorrectly, sometimes multiple distinct solutions for the same problems. We looked at the application vulnerabilities. Scanning is valuable but it will not distinguish why applications are broken. His findings were:

* 35% of vulnerabilities had no controls.
* 30 percent of application controls were broken and ineffective.
* 20 percent were ignored. This is harder than just giving developers the controls. So we need to make the controls easier to use.
* 15 percent of controls were not used correctly. Ease of use is necessary for this case as well.

'''Security Controls are Hard'''

There are 1.6 quadrillion or 785 ways to encode a character in canonical form. We need to make it simpler for the developers to use the controls. We want to pull the controls out of the code and put them in a application security control library for the developers to use. We want to manage security instead of insecurity. Controls instead of threats. Patterns instead of vulnerabilities. If you manage vulnerabilities and patches, the problems quickly become unmanageable. If you manage assurance, you can get ahead of the vulnerabilities by stamping large classes of vulnerabilities at a time. We identified 100 methods with a common application programming interface (API).

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development. You cant just download ESAPI and use it out of the wrapper. Each organization needs to create its own security library.

Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design:
* There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls.
* There is a reference implementation for each security control. The logic is not organization specific and the logic is not application specific. An example: string based input validation.
* There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

There are ESAPI tools for Java, .NET, PHP, Cold Fusion, ASP, Python, AJAX (Javascript on the client side), Ruby, C, and Salesforce.com. Also, with ESAPI each application could have its own web application firewall. The WAF can implement a virtual patch, check session states, user authentication, and other application characteristics.

When an attack comes out, we can review our code and make patches so that all developers using ESAPI will benefit. Taking an assurance case perspective, we built almost a thousand test cases. We have tests for canonicalization, output escaping. Also we can establish user identification and access control. We have run Fortify, AppScan (Once Labs), and PMD. The output from FindBugs is interesting. Do all my Sturts action make sequential calls to authentication and logger?

Why invest in application security? There is a business and ROI. Also appsec enables innovation, it allows organizations to do things they can’t do today.

Q. What is the training requirement?
A. It is difficult to teach developers to teach all about application security. It is far easier to teach an API in their own language. ESAPI simplifies the learning process. You can cover ESPAI in a day for a decent Java developer.

See the [The Design and Evaluation of INFOSEC Systems: The Computer Security Contribution http://www.csirt.org/color_%20books/C-TR-32-92.pdf] in the rainbow series by Mario Tinto

In order for the firewall to determine if the request is malevolent. The application understands the business rules whereas the firewall does not. ESAPI makes the code a lot simpler and easier to figure out what the policy being enforced.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 ESAPI

2010-10-05T19:30:23Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Enterprise Security API, or ESAPI

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_ESAPI.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

==Notes ==
;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI is a free and open collection of all the security methods that a developer needs to build a secure web application. (Assessment Criteria v1.0)

Several years ago, Williams was asked to review applications supported by a development shop. He discovered that every developer was reinventing code, and doing it incorrectly, sometimes multiple distinct solutions for the same problems. We looked at the application vulnerabilities. Scanning is valuable but it will not distinguish why applications are broken. His findings were:

* 35% of vulnerabilities had no controls.
* 30 percent of application controls were broken and ineffective.
* 20 percent were ignored. This is harder than just giving developers the controls. So we need to make the controls easier to use.
* 15 percent of controls were not used correctly. Ease of use is necessary for this case as well.

'''Security Controls are Hard'''

There are 1.6 quadrillion or 785 ways to encode a character in canonical form. We need to make it simpler for the developers to use the controls. We want to pull the controls out of the code and put them in a application security control library for the developers to use. We want to manage security instead of insecurity. Controls instead of threats. Patterns instead of vulnerabilities. If you manage vulnerabilities and patches, the problems quickly become unmanageable. If you manage assurance, you can get ahead of the vulnerabilities by stamping large classes of vulnerabilities at a time. We identified 100 methods with a common application programming interface (API).

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development. You cant just download ESAPI and use it out of the wrapper. Each organization needs to create its own security library.

Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design:
* There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls.
* There is a reference implementation for each security control. The logic is not organization specific and the logic is not application specific. An example: string based input validation.
* There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

There are ESAPI tools for Java, .NET, PHP, Cold Fusion, ASP, Python, AJAX (Javascript on the client side), Ruby, C, and Salesforce.com. Also, with ESAPI each application could have its own web application firewall. The WAF can implement a virtual patch, check session states, user authentication, and other application characteristics.

When an attack comes out, we can review our code and make patches so that all developers using ESAPI will benefit. Taking an assurance case perspective, we built almost a thousand test cases. We have tests for canonicalization, output escaping. Also we can establish user identification and access control. We have run Fortify, AppScan (Once Labs), and PMD. The output from FindBugs is interesting. Do all my Sturts action make sequential calls to authentication and logger?

Why invest in application security? There is a business and ROI. Also appsec enables innovation, it allows organizations to do things they can’t do today.

Q. What is the training requirement?
A. It is difficult to teach developers to teach all about application security. It is far easier to teach an API in their own language. ESAPI simplifies the learning process. You can cover ESPAI in a day for a decent Java developer.

See the [The Design and Evaluation of INFOSEC Systems: The Computer Security Contributionhttp://www.csirt.org/color_%20books/C-TR-32-92.pdf] in the rainbow series by Mario Tinto

In order for the firewall to determine if the request is malevolent. The application understands the business rules whereas the firewall does not. ESAPI makes the code a lot simpler and easier to figure out what the policy being enforced.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 ESAPI

2010-10-05T19:25:21Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Enterprise Security API, or ESAPI

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_ESAPI.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

==Notes ==
;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI is a free and open collection of all the security methods that a developer needs to build a secure web application. (Assessment Criteria v1.0)

Several years ago, Williams was asked to review applications supported by a development shop. He discovered that every developer was reinventing code, and doing it incorrectly, sometimes multiple distinct solutions for the same problems. We looked at the application vulnerabilities. Scanning is valuable but it will not distinguish why applications are broken. His findings were:

* 35% of vulnerabilities had no controls.
* 30 percent of application controls were broken and ineffective.
* 20 percent were ignored. This is harder than just giving developers the controls. So we need to make the controls easier to use.
* 15 percent of controls were not used correctly. Ease of use is necessary for this case as well.

'''Security Controls are Hard'''

There are 1.6 quadrillion or 785 ways to encode a character in canonical form. We need to make it simpler for the developers to use the controls. We want to pull the controls out of the code and put them in a application security control library for the developers to use. We want to manage security instead of insecurity. Controls instead of threats. Patterns instead of vulnerabilities. If you manage vulnerabilities and patches, the problems quickly become unmanageable. If you manage assurance, you can get ahead of the vulnerabilities by stamping large classes of vulnerabilities at a time. We identified 100 methods with a common application programming interface (API).

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development. You cant just download ESAPI and use it out of the wrapper. Each organization needs to create its own security library.

Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design:
* There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls.
* There is a reference implementation for each security control. The logic is not organization specific and the logic is not application specific. An example: string based input validation.
* There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

There are ESAPI tools for Java, .NET, PHP, Cold Fusion, ASP, Python, AJAX (Javascript on the client side), Ruby, C, and Salesforce.com. Also, with ESAPI each application could have its own web application firewall. The WAF can implement a virtual patch, check session states, user authentication, and other application characteristics.

When an attack comes out, we can review our code and make patches so that all developers using ESAPI will benefit. Taking an assurance case perspective, we built almost a thousand test cases. We have tests for canonicalization, output escaping. Also we can establish user identification and access control. We have run Fortify, AppScan (Once Labs), and PMD. The output from FindBugs is interesting. Do all my Sturts action make sequential calls to authentication and logger?

Why invest in application security? There is a business and ROI. Also appsec enables innovation, it allows organizations to do things they can’t do today.

Q. What is the training requirement?
A. It is difficult to teach developers to teach all about application security. It is far easier to teach an API in their own language. ESAPI simplifies the learning process. You can cover ESPAI in a day for a decent Java developer.

See the composition paper in the rainbow series by Mario Tinto.

In order for the firewall to determine if the request is malevolent. The application understands the business rules whereas the firewall does not. ESAPI makes the code a lot simpler and easier to figure out what the policy being enforced.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 ESAPI

2010-10-05T19:23:11Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Enterprise Security API, or ESAPI

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_ESAPI.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

==Notes ==
;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

ESAPI is a free and open collection of all the security methods that a developer needs to build a secure web application. (Assessment Criteria v1.0)

Several years ago, Williams was asked to review applications supported by a development shop. He discovered that every developer was reinventing code, and doing it incorrectly, sometimes multiple distinct solutions for the same problems. We looked at the application vulnerabilities. Scanning is valuable but it will not distinguish why applications are broken. Our findings were:
• 35% of vulnerabilities had no controls.
• 30 percent of application controls were broken and ineffective.
• 20 percent were ignored. This is harder than just giving developers the controls. So we need to make the controls easier to use.
• 15 percent of controls were not used correctly. Ease of use is necessary for this case as well.
Security Controls are Hard
There are 1.6 quadrillion or 785 ways to encode a character in canonical form. We need to make it simpler for the developers to use the controls. We want to pull the controls out of the code and put them in a application security control library for the developers to use. We want to manage security instead of insecurity. Controls instead of threats. Patterns instead of vulnerabilities. If you manage vulnerabilities and patches, the problems quickly become unmanageable. If you manage assurance, you can get ahead of the vulnerabilities by stamping large classes of vulnerabilities at a time. We identified 100 methods with a common application programming interface (API).

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development. You cant just download ESAPI and use it out of the wrapper. Each organization needs to create its own security library.

Allowing for language-specific differences, all OWASP ESAPI versions have the same basic design:
• There is a set of security control interfaces. They define for example types of parameters that are passed to types of security controls.
• There is a reference implementation for each security control. The logic is not organization specific and the logic is not application specific. An example: string based input validation.
• There are optionally your own implementations for each security control. There may be application logic contained in these classes which may be developed by or for your organization. An example: enterprise authentication.

There are ESAPI tools for Java, .NET, PHP, Cold Fusion, ASP, Python, AJAX (Javascript on the client side), Ruby, C, and Salesforce.com. Also, with ESAPI each application could have its own web application firewall. The WAF can implement a virtual patch, check session states, user authentication, and other application characteristics.

When an attack comes out, we can review our code and make patches so that all developers using ESAPI will benefit. Taking an assurance case perspective, we built almost a thousand test cases. We have tests for canonicalization, output escaping. Also we can establish user identification and access control. We have run Fortify, AppScan (Once Labs), and PMD. The output from FindBugs is interesting. Do all my Sturts action make sequential calls to authentication and logger?

Why invest in application security? There is a business and ROI. Also appsec enables innovation, it allows organizations to do things they can’t do today.

Q. What is the training requirement?
A. It is difficult to teach developers to teach all about application security. It is far easier to teach an API in their own language. ESAPI simplifies the learning process. You can cover ESPAI in a day for a decent Java developer.

See the composition paper in the rainbow series by Mario Tinto.

In order for the firewall to determine if the request is malevolent. The application understands the business rules whereas the firewall does not. ESAPI makes the code a lot simpler and easier to figure out what the policy being enforced.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T19:17:03Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation on the OpenSAMM Maturity Model, and how it can be used to start or shape a software assurance program.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Shakeel_Tufail_2010-09_OWASP_DHS_SWA_Day_-_OpenSAMM.ppt | Download the presentation]] -- ''Note, some of the images have been removed to reduce file size for download.''

== The speaker ==

A speaker bio for Shakeel Tufail will be posted shortly.

== Notes ==

;[[:Category:Software Assurance Maturity Model|Software Assurance Maturity Model (SAMM)]]
The Open SAMM project is committed to building a usable framework to help organizations formulate and implement a strategy for application security that's tailored to the specific business risks facing the organization.

SAMM is used as a measuring stick against an organization’s security practices and functions. OpenSAMM is a maturity model should be used as a scorecard for improving software assurance and provides prescriptive guidance for technical and non-technical users.

SAMM divides the SDLC into the governance, construction, verification, and deployment business functions consisting of 12 security practices. Each practice is a silo for improvement that can be performed independently or as part of a plan. The maturity of each practice is scored from 0 to 3.

The approach of SAMM is iterative and the goal is to have a phased approach to assess which areas need the most work and prioritize. The initial results are used to create a baseline roadmap from which the phased approach would be developed. The resulting scorecard provides a basis to perform a gap analysis.

A new OpenSAMM version will include new functionality of analyzing feedback, case studies, and mapping of OpenSAMM to other regulations such as PCI, COBIT, CMMI, and FISMA.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OWASP WTE

2010-10-05T19:13:29Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]A presentation about the OWASP Web Testing Environment, previously the OWASP Live CD.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Matt_Tesauro_2010-09_OWASP_DHS_SWA_Day_-_WTE.ppt | Download the presentation]]

== The speaker ==

A speaker Bio for Matt Tesauro will be posted shortly.

== Notes ==
;[[:Category:OWASP LiveCD Education Project|OWASP Live CD Education Project]]

The OWASP Live CD is an educational supplement project containing tutorials, challenges and videos detailing the use of tools contained within the OWASP LiveCD - LabRat. This project was sponsored by [[OWASP Spring Of Code 2007|OWASP Spring Of Code 2007]] and [http://www.securitydistro.com/ Security Distro] (Assessment Criteria v1.0)

It’s hard to be a tester if you have never been a developer. The goal of the CD was originally to create a ready-made environment in which to perform testing. The CD showcases great tools and contains not only OWASP tools.

The design goals include being easy to keep users up to date while being easy to update.There were gaps between the tools and the testing guides. The goal is to keep them aligned.

The OWASP Web Testing Environment (WTE) is the new name of the DVD which includes 26 significant tools. WTE also includes Firefox security add-ons, OWASP documents, a Top 10 risks list, VM software, and many other. WTE is also used as an education tool. The Webgoat tool is already being used for training classes.

WTE consists of more tools focused on developing instead of testing focused; there are more tools available via a repository for packages. Each tool will now automatically install dependent tools. WTE now runs on Ubuntu and each tool has its own Debian package. You can mix and match packages for only what you need to use. Some new features to be added in future versions are virtual installs, USB bootable install, customized versions of WTE via a la carte builds.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OpenSAMM

2010-10-05T19:04:58Z

Walter Houser:

OWASP DHS SWA Day 2010 OWASP

2010-10-04T22:13:54Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An introduction to the OWASP mission.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_OWASP.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

== Notes ==

Introduction to OWASP – Jeff Williams takes a different view of assurance. He is promoting the assurance view into high speed software development. Also he will explain how OWASP works and the methods used to change the world. These are ideas that can actually change the game.

“Security is a process, not a product.” If security is a process we could just follow it. Security is more like an artifact of a process; an emergent characteristic of following a procedss. We in OWASP like to look at security as an eco-system.

Background – There are roughly 10 million developers writing code and about a trillion lines of code. If there were just 100 developers looking at 100 apps for 100 organizations.
* 83 apps would have a serious vulnerability
* 72 apps would have XSS
* 40 would have SQL injection
* 1 company would have responsible appsec program (rounded up)
* 1 developer would have any security training
* All applications would have code from unknown origin
* 90 apps use libraries with known unpatched holes
* 5 apps have has some sort of scan or test
* 1 app has had a manual code review (rounded up)
* There is no amount of automation that can find the problems
* 0 apps provide any visibility into security
Every website has a privacy page, but none have a security page.

How do you want the world to be? Is this acceptable? We trust this software. Software is becoming more and more complicated every day. We are connecting our architectures at an amazing rate. We trust it to do more sensitive things.

Three forces: complexity, connectivity, criticality – create a perfect storm of insecurity

What is stopping us from having assurance?
1. Trust – we trust the internet, we naturally trust software, we assume no vulnerabilities instead of the other way around of having to be proven
2. Blame – we instantly blame the developers.
3. Hide – we hide security. When developers are blamed, they hide their security measures.

These three aspects create a toxic eco-system. We have no other option than to trust due to this system.
This is a self-enforcing cycle that keeps security down.

OWASP’s mission is focused on visibility to break the cycle. OWASP is working toward a security facts label (like a food nutrition label)

There is an underlying economic principle at work. At markets where there is asymmetric information, it is very difficult for consumers to get a fair price. When you buy software you have no idea if it is a lemon so you cannot get a fair price for security. Until we fix the software market, nothing else matters. We will not get secure code out of it. See the 1970 paper by the economist George Akerlof [http://en.wikipedia.org/wiki/The_Market_for_Lemons The Market for Lemons ]. Ross Anderson’s paper [http://www.acsac.org/2001/papers/110.pdf Why Information Security Is So Hard ] also discusses the ecomonic challenges facing security practitioners.

OWASP is an eco-system. An OWASP intern started the [http://www.Pythonsecurity.org Pythonsecurity.org ] project due to a void of information. These ecosystems pull together information, a community, etc. There are builders and breakers working together for security. Security is co-evolutionary. The bad guys break in, the good guys add more defenses, repeatedly. This is the process that generates security.

Evolution of an ecosystem – individual, website, contributors, self-sustaining, etc.

OWASP is trying to bootstrap lots of ecosystems like this Python Security ecosystem. OWASP operates on a shoestring budget. It has only two full time employees. It is a 501c3 organization. OWASP just began the college chapters program. This program seeks to embed security knowledge into all colleges with computer science degrees.

OWASP offers many conferences around the world. OWASP works with industry. OWASP has a connections committee to bring together people who need to speak to each other to improve security. OWASP receives approximately 15000 page views on its website. Last week when twitter was infected with the XSS worm, there was a large spike in traffic.

The reasoning behind the agenda: start narrow with things you can use now, then expose you to ways to improve security, show you the OWASP live compact disc (CD), then move toward success stories from implementing the DISA STIG.

While consumers may not be risking a significant amount, there are companies that are losing millions of dollars per day, and this does not need to be happening.

Q. How do you get a developer passionate about security? What made the community shift toward focusing on security?

A. Developers want to do the right thing and build secure code. There is a lot for developers to learn. I don’t think we can expect developers to become security experts. We need to focus on making security easier for developers. We should take security out of their hands and put it into standards and tools. Visibility is at the core of the solution to get people focused on it and to improve.

Q. You mentioned critical infrastructure and legacy. What is OWAPS’s position on legacy systems? There must be an interim solution.

A. There has to be an interim because of the vast amount of lines of code. We need to take the same approach with new systems. Identify the risk, prioritize the risks, and then put controls in place to counter them. We become hypnotized by little problems that are revealed by tools, but we miss the larger more important risks that may not be as easy to detect.

Q. Is there a roadmap for APIs?
A. We will cover that in the ESAPI presentation.

Q. So many people think of other types of security other than application security. How can we bridge these two communities?

A. We have had challenges turning network security folks into software security folks. We have had luck with making developers more aware of software security. There is more work to be done.

Q. There is a large knowledge gap between the developers and the security folks that have never written a line of code. Could OWASP do anything to point out the knowledge gap?

A. There is no silver bullet. The solution is complex. If a new cycle of visibility and collaboration can be created, then this would make a big difference. We have an issue of many compliance and security people that are not engineers. They are analyzing artifacts without understanding the fundamental pathways of how the code works. There are no people in between the developers and the assessors. We need people who understand both to serve this intermediate position. We either need to teach security people engineering or vice versa.

When you think of software assurance, please don’t confuse all of this with verification. Verification is not application security. We should spend 80% building it right, then 10% checking, then 10% for other things.

--[[User:Walter Houser|Walter Houser]] 22:13, 4 October 2010 (UTC)

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 Getting Started

2010-10-04T22:13:08Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An overview of the OWASP Top Ten, the OWASP ASVS, and the OWASP Guides.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Dave_Wichers_2010-09_OWASP_DHS_SWA_Day_-_OWASP_Projects.pptx | Download the presentation]]

== The speaker ==

Dave Wichers is a cofounder and the Chief Operating Officer (COO) of [http://www.aspectsecurity.com Aspect Security], a company that specializes in application security services.

As a volunteer to OWASP, Dave is:

* A member of the [[About_OWASP#Global_Board_Members|OWASP Board]],
* The [[:Category:OWASP_AppSec_Conference | OWASP Conferences]] Chair,
* Project lead and coauthor of the [[OWASP_Top_Ten_Project | OWASP Top 10]],
* Coauthor of the [[ASVS | OWASP Application Security Verification Standard]], and
* Contributor to the [[ESAPI | OWASP Enterprise Security API (ESAPI)]] project.

Dave has over 20 years of experience in the information security field, and has focused exclusively on application security since 1998. At Aspect, in addition to his COO duties, he is Aspect's application security courseware lead, one of their chief instructors, and provides a wide variety of application security consulting services to Aspect's clients. Prior to starting Aspect, he ran the Application Security Services Group at Exodus Communications. Dave has a Bachelors and Masters degree in Computer Science, is a CISSP, and a CISM.

Dave can be reached at: dave.wichers (at) aspectsecurity.com or dave.wichers (at) owasp.org

== Notes ==

'''Getting Started with the Top Ten and OWASP Guides'''
– Dave Wichers
We are still not asking for secure software. Is your customer really asking you to create secure software? There is a fundamental supply and demand problem. No one will produce something that no one wants to buy. If software firms spend the effort to build secure software, then it increases the cost. If it has the same functionality but has the invisible feature of security, then no one will buy it yet. We as consumers must demand security from these companies we patronize. Microsoft has worked very hard to produce secure software. Some vendors are starting to win contracts because their software is more secure.

Microsoft was seeing roughly 8 – 15% of up front costs, but then saw costs drop dramatically due to efficiencies and cost avoidance. Investing in software quality can also provide a means for cost reduction which is a huge culture problem.

Startups only care about marketshare, not security. Small companies should have security as a priority as they gain a certain portion of marketshare.

Open Source is not necessarily more or less secure. It varies. DHS’ HOST program and another site setup in partnership with Coverity provide feedback to open source developers.

When Wichers works with the DISA STIGs he look at the code to see if it is secure. If he finds something, they fix it. If not, then they don’t fix it. They are focusing on verification. If there is enough flaws found, then they might ask if there is a better way to build security in. But if we don’t demand security then we won’t get it.

Wichers discussed half a dozen projects, but OWASP has many more in various levels of maturity. There is a bar at the top of the OWASP website that lists some of the most mature projects. The OWASP meritocracy allows members to start new projects and then gain traction. There are slide decks on each OWASP project available online.

Many are listing OWASP references in either strong or weak ways. PCI point directly to the OWASP Top 10 despite having no formal relationship. The DISA STIG makes many references to the Top 10 for more information.

;[[:Category:OWASP Top Ten Project|OWASP Top Ten Project]]
'''Top 10 Web Application Security Risks'''

The first step to helping developers is to make them aware of the issues. The Top 10 is a broad brush awareness document for any community. But it won’t provide all the details. If you don’t understand the technical foundation of the problems then you can’t build code to be secure against them.

The Top 10 helps developers to understand risk. Businesses must understand the risks and how significant they are. The business must understand the gravity of the ramifications if this risk is exploited. Until the business understands the risk, they won’t do anything about it.

The managers must care for the developers to care. The Top 10 includes a section stating that it is related to risk instead of just technical specifications. Businesses understand and are concerned with risk. Everything is a cost-benefit balance.

The attacks are becoming extremely professional and advanced. Economic pressures may not come as strongly from the consumers who are “path-of-least-resistance driven” but business-to-business pressure will be much stronger. This has been seen in the credit card processing industry. Google removed all of its internal Microsoft operating system installations after the Chinese hack.

The OWASP material ranges from understanding risk, to avoiding risk, to measuring risk, to managing risk.

Microsoft has statistics about the cost of the appsec program being zero or negative because the cost of rework outweighs their investment. This information is publicly available. Over time the up front cost is reduced.

The Top 10 was created in 2003. Each year it has been condensed so it is easily consumable. The Top 10 was always about risk, but making this distinction has been made clearer. Although some flaws may be less prevalent, they are just as devastating when exploited. The Top 10 is prioritized based upon the OWASP Risk Rating Methodology.

'''The OWASP Prevention Cheat Sheet''' provides article on how to avoid the most common web security problems. They are all interlinked. They include very concise guidance for developers.

;[[:Category:OWASP Application Security Verification Standard Project|OWASP Application Security Verification Standard Project]]
'''The OWASP Application Security Verification Standard (ASVS)''' provides a standard for how to verify security services. This helps organizations to compare application security service vendors. The ASVS is a positive model stating what should be found. The byproduct is a comprehensive roadmap of requirements which other OWASP ecosystems could leverage. The standard is our opinion of what should be included. The ASVS is a verification standard and is organized in terms of level of difficulty. This is why automated verification is at level 1 and design verification is at level 3.

;[[:Category:OWASP Legal Project|OWASP Legal Project]]
The government needs to ask for secure software in any form. '''The OWASP Legal Guide''' facilitates the requiring of secure software in contracts. Its use would require a smart purchaser of security to require it of their vendor and having it as a factor of competitive bidding.

Q. Have any vendors adopted the legal language?
A. A few companies have experimented with the legal language.

;[[:Category:OWASP Guide Project|OWASP Development Guide]]
'''The OWASP Developer Guide''' was the original flagship document. The document has languished but there is a team that is working to update it.

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

Developers need secure controls to build secure software. This document explains the intent of this statement. It outlines the standard set of controls needed and provides an explanation of the implementation. It outlines standard control implementation in many popular languages. The ESAPI source code is a great example of secure code. There are plenty of other free OWASP tools online as well.

;[[:Category:OWASP Code Review Project|OWASP Code Review Guide]]
'''The OWASP Code Review Guide''' outlines approaches to code review, reporting, metrics, etc. by example within various languages. It will soon be aligned with the ASVS.

;[[:Category:OWASP Testing Project|OWASP Testing Guide]]
'''The OWASP Testing Guide''' may be the largest OWASP project in terms of the number of contributors. This may be the most popular guide due to the number of people trying to perform testing.

;[http://www.owasp.org/index.php/Common_OWASP_Numbering OWASP Common Numbering] project organizes the guides in the same standardized order.

;[[OWASP Secure Coding Practices - Quick Reference Guide|OWASP Secure Coding Practices - Quick Reference Guide]]

[[Category:OWASP_Conference_Presentations]]
--[[User:Walter Houser|Walter Houser]] 22:13, 4 October 2010 (UTC)

OWASP DHS SWA Day 2010 Getting Started

2010-10-04T22:12:46Z

Walter Houser:

OWASP DHS SWA Day 2010 Getting Started

2010-10-04T21:55:27Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An overview of the OWASP Top Ten, the OWASP ASVS, and the OWASP Guides.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Dave_Wichers_2010-09_OWASP_DHS_SWA_Day_-_OWASP_Projects.pptx | Download the presentation]]

== The speaker ==

Dave Wichers is a cofounder and the Chief Operating Officer (COO) of [http://www.aspectsecurity.com Aspect Security], a company that specializes in application security services.

As a volunteer to OWASP, Dave is:

* A member of the [[About_OWASP#Global_Board_Members|OWASP Board]],
* The [[:Category:OWASP_AppSec_Conference | OWASP Conferences]] Chair,
* Project lead and coauthor of the [[OWASP_Top_Ten_Project | OWASP Top 10]],
* Coauthor of the [[ASVS | OWASP Application Security Verification Standard]], and
* Contributor to the [[ESAPI | OWASP Enterprise Security API (ESAPI)]] project.

Dave has over 20 years of experience in the information security field, and has focused exclusively on application security since 1998. At Aspect, in addition to his COO duties, he is Aspect's application security courseware lead, one of their chief instructors, and provides a wide variety of application security consulting services to Aspect's clients. Prior to starting Aspect, he ran the Application Security Services Group at Exodus Communications. Dave has a Bachelors and Masters degree in Computer Science, is a CISSP, and a CISM.

Dave can be reached at: dave.wichers (at) aspectsecurity.com or dave.wichers (at) owasp.org

== Notes ==

'''Getting Started with the Top Ten and OWASP Guides'''
– Dave Wichers
We are still not asking for secure software. Is your customer really asking you to create secure software? There is a fundamental supply and demand problem. No one will produce something that no one wants to buy. If I spend the effort to build secure software, then it increases the cost. If it has the same functionality but has the invisible feature of security, then no one will buy it yet. We as consumers must demand security from these companies we patronize. Microsoft has worked very hard to produce secure software. Some vendors are starting to win contracts because their software is more secure.

Microsoft was seeing roughly 8 – 15% of up front costs, but then saw costs drop dramatically due to efficiencies and cost avoidance. Investing in software quality can also provide a means for cost reduction which is a huge culture problem.

Startups only care about marketshare, not security. Small companies should have security as a priority as they gain a certain portion of marketshare.

Open Source is not necessarily more or less secure. It varies. DHS’ HOST program and another site setup in partnership with Coverity provide feedback to open source developers.

When Wichers works with the DISA STIGs he look at the code to see if it is secure. If he finds something, they fix it. If not, then they don’t fix it. They are focusing on verification. If there is enough flaws found, then they might ask if there is a better way to build security in. But if we don’t demand security then we won’t get it.

Wichers discussed half a dozen projects, but OWASP has many more in various levels of maturity. There is a bar at the top of the OWASP website that lists some of the most mature projects. The OWASP meritocracy allows members to start new projects and then gain traction. There are slide decks on each OWASP project available online.

Many are listing OWASP references in either strong or weak ways. PCI point directly to the OWASP Top 10 despite having no formal relationship. The DISA STIG makes many references to the Top 10 for more information.

;[[:Category:OWASP Top Ten Project|OWASP Top Ten Project]]
'''Top 10 Web Application Security Risks'''

The first step to helping developers is to make them aware of the issues. The Top 10 is a broad brush awareness document for any community. But it won’t provide all the details. If you don’t understand the technical foundation of the problems then you can’t build code to be secure against them.

The Top 10 helps developers to understand risk. Businesses must understand the risks and how significant they are. The business must understand the gravity of the ramifications if this risk is exploited. Until the business understands the risk, they won’t do anything about it.

The managers must care for the developers to care. The Top 10 includes a section stating that it is related to risk instead of just technical specifications. Businesses understand and are concerned with risk. Everything is a cost-benefit balance.

The attacks are becoming extremely professional and advanced. Economic pressures may not come as strongly from the consumers who are “path-of-least-resistance driven” but business-to-business pressure will be much stronger. This has been seen in the credit card processing industry. Google removed all of its internal Microsoft operating system installations after the Chinese hack.

The OWASP material ranges from understanding risk, to avoiding risk, to measuring risk, to managing risk.

Microsoft has statistics about the cost of the appsec program being zero or negative because the cost of rework outweighs their investment. This information is publicly available. Over time the up front cost is reduced.

The Top 10 was created in 2003. Each year it has been condensed so it is easily consumable. The Top 10 was always about risk, but making this distinction has been made clearer. Although some flaws may be less prevalent, they are just as devastating when exploited. The Top 10 is prioritized based upon the OWASP Risk Rating Methodology.

'''The OWASP Prevention Cheat Sheet''' provides article on how to avoid the most common web security problems. They are all interlinked. They include very concise guidance for developers.

;[[:Category:OWASP Application Security Verification Standard Project|OWASP Application Security Verification Standard Project]]
'''The OWASP Application Security Verification Standard (ASVS)''' provides a standard for how to verify security services. This helps organizations to compare application security service vendors. The ASVS is a positive model stating what should be found. The byproduct is a comprehensive roadmap of requirements which other OWASP ecosystems could leverage. The standard is our opinion of what should be included. The ASVS is a verification standard and is organized in terms of level of difficulty. This is why automated verification is at level 1 and design verification is at level 3.

;[[:Category:OWASP Legal Project|OWASP Legal Project]]
The government needs to ask for secure software in any form. '''The OWASP Legal Guide''' facilitates the requiring of secure software in contracts. Its use would require a smart purchaser of security to require it of their vendor and having it as a factor of competitive bidding.

Q. Have any vendors adopted the legal language?
A. A few companies have experimented with the legal language.

;[[:Category:OWASP Guide Project|OWASP Development Guide]]
'''The OWASP Developer Guide''' was the original flagship document. The document has languished but there is a team that is working to update it.

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

Developers need secure controls to build secure software. This document explains the intent of this statement. It outlines the standard set of controls needed and provides an explanation of the implementation. It outlines standard control implementation in many popular languages. The ESAPI source code is a great example of secure code. There are plenty of other free OWASP tools online as well.

;[[:Category:OWASP Code Review Project|OWASP Code Review Guide]]
'''The OWASP Code Review Guide''' outlines approaches to code review, reporting, metrics, etc. by example within various languages. It will soon be aligned with the ASVS.

;[[:Category:OWASP Testing Project|OWASP Testing Guide]]
'''The OWASP Testing Guide''' may be the largest OWASP project in terms of the number of contributors. This may be the most popular guide due to the number of people trying to perform testing.

OWASP Common Numbering project organizes the guides in the same standardized order.

;[[OWASP Secure Coding Practices - Quick Reference Guide|OWASP Secure Coding Practices - Quick Reference Guide]]

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 Getting Started

2010-10-04T21:48:50Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An overview of the OWASP Top Ten, the OWASP ASVS, and the OWASP Guides.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Dave_Wichers_2010-09_OWASP_DHS_SWA_Day_-_OWASP_Projects.pptx | Download the presentation]]

== The speaker ==

Dave Wichers is a cofounder and the Chief Operating Officer (COO) of [http://www.aspectsecurity.com Aspect Security], a company that specializes in application security services.

As a volunteer to OWASP, Dave is:

* A member of the [[About_OWASP#Global_Board_Members|OWASP Board]],
* The [[:Category:OWASP_AppSec_Conference | OWASP Conferences]] Chair,
* Project lead and coauthor of the [[OWASP_Top_Ten_Project | OWASP Top 10]],
* Coauthor of the [[ASVS | OWASP Application Security Verification Standard]], and
* Contributor to the [[ESAPI | OWASP Enterprise Security API (ESAPI)]] project.

Dave has over 20 years of experience in the information security field, and has focused exclusively on application security since 1998. At Aspect, in addition to his COO duties, he is Aspect's application security courseware lead, one of their chief instructors, and provides a wide variety of application security consulting services to Aspect's clients. Prior to starting Aspect, he ran the Application Security Services Group at Exodus Communications. Dave has a Bachelors and Masters degree in Computer Science, is a CISSP, and a CISM.

Dave can be reached at: dave.wichers (at) aspectsecurity.com or dave.wichers (at) owasp.org

== Notes ==

'''Getting Started with the Top Ten and OWASP Guides'''
– Dave Wichers
We are still not asking for secure software. Is your customer really asking you to create secure software? There is a fundamental supply and demand problem. No one will produce something that no one wants to buy. If I spend the effort to build secure software, then it increases the cost. If it has the same functionality but has the invisible feature of security, then no one will buy it yet. We as consumers must demand security from these companies we patronize. Microsoft has worked very hard to produce secure software. Some vendors are starting to win contracts because their software is more secure.

Microsoft was seeing roughly 8 – 15% of up front costs, but then saw costs drop dramatically due to efficiencies and cost avoidance. Investing in software quality can also provide a means for cost reduction which is a huge culture problem.

Startups only care about marketshare, not security. Small companies should have security as a priority as they gain a certain portion of marketshare.

Open Source is not necessarily more or less secure. It varies. DHS’ HOST program and another site setup in partnership with Coverity provide feedback to open source developers.

When I work with the DISA STIGs I look at the code to see if it is secure. If I find something, they fix it. If I don’t, then they don’t fix it. They are focusing on verification. If there is enough flaws found, then they might ask if there is a better way to build security in. But if we don’t demand security then we won’t get it.

I am going to discuss half a dozen projects, but OWASP has many more in various levels of maturity. There is a bar at the top of the OWASP website that lists some of the most mature projects. The OWASP meritocracy allows members to start new projects and then gain traction.

Many are listing OWASP references in either strong or weak ways. PCI point directly to the OWASP Top 10 despite having no formal relationship. The DISA STIG makes many references to the Top 10 for more information.

;[[:Category:OWASP Top Ten Project|OWASP Top Ten Project]]
'''Top 10 Web Application Security Risks'''

The first step to helping developers is to make them aware of the issues. The Top 10 is a broad brush awareness document for any community. But it won’t provide all the details. If you don’t understand the technical foundation of the problems then you can’t build code to be secure against them.

The Top 10 helps developers to understand risk. Businesses must understand the risks and how significant they are. The business must understand the gravity of the ramifications if this risk is exploited. Until the business understands the risk, they won’t do anything about it.

The managers must care for the developers to care. The Top 10 includes a section stating that it is related to risk instead of just technical specifications. Businesses understand and are concerned with risk. Everything is a cost-benefit balance.

The attacks are becoming extremely professional and advanced. Economic pressures may not come as strongly from the consumers who are “path-of-least-resistance driven” but business-to-business pressure will be much stronger. This has been seen in the credit card processing industry. Google removed all of its internal Microsoft operating system installations after the Chinese hack.

The OWASP material ranges from understanding risk, to avoiding risk, to measuring risk, to managing risk.

Microsoft has statistics about the cost of the appsec program being zero or negative because the cost of rework outweighs their investment. This information is publicly available. Over time the up front cost is reduced.

The Top 10 was created in 2003. Each year it has been condensed so it is easily consumable. The Top 10 was always about risk, but making this distinction has been made clearer. Although some flaws may be less prevalent, they are just as devastating when exploited. The Top 10 is prioritized based upon the OWASP Risk Rating Methodology.

'''The OWASP Prevention Cheat Sheet''' provides article on how to avoid the most common web security problems. They are all interlinked. They include very concise guidance for developers.

;[[:Category:OWASP Application Security Verification Standard Project|OWASP Application Security Verification Standard Project]]
'''The OWASP Application Security Verification Standard (ASVS)''' provides a standard for how to verify security services. This helps organizations to compare application security service vendors. The ASVS is a positive model stating what should be found. The byproduct is a comprehensive roadmap of requirements which other OWASP ecosystems could leverage. The standard is our opinion of what should be included. The ASVS is a verification standard and is organized in terms of level of difficulty. This is why automated verification is at level 1 and design verification is at level 3.

;[[:Category:OWASP Legal Project|OWASP Legal Project]]
The government needs to ask for secure software in any form. '''The OWASP Legal Guide''' facilitates the requiring of secure software in contracts. Its use would require a smart purchaser of security to require it of their vendor and having it as a factor of competitive bidding.

Q. Have any vendors adopted the legal language? A few companies have experimented with the legal language.
A. There are slide decks on each OWASP project available online.

;[[:Category:OWASP Guide Project|OWASP Development Guide]]
'''The OWASP Developer Guide''' was the original flagship document. The document has languished but there is a team that is working to update it.

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]

Developers need secure controls to build secure software. This document explains the intent of this statement. It outlines the standard set of controls needed and provides an explanation of the implementation. It outlines standard control implementation in many popular languages. The ESAPI source code is a great example of secure code. There are plenty of other free OWASP tools online as well.

;[[:Category:OWASP Code Review Project|OWASP Code Review Guide]]
'''The OWASP Code Review Guide''' outlines approaches to code review, reporting, metrics, etc. by example within various languages. It will soon be aligned with the ASVS.

;[[:Category:OWASP Testing Project|OWASP Testing Guide]]
'''The OWASP Testing Guide''' may be the largest OWASP project in terms of the number of contributors. This may be the most popular guide due to the number of people trying to perform testing.

OWASP Common Numbering project organizes the guides in the same standardized order.

;[[OWASP Secure Coding Practices - Quick Reference Guide|OWASP Secure Coding Practices - Quick Reference Guide]]

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 Getting Started

2010-10-04T21:43:23Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An overview of the OWASP Top Ten, the OWASP ASVS, and the OWASP Guides.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Dave_Wichers_2010-09_OWASP_DHS_SWA_Day_-_OWASP_Projects.pptx | Download the presentation]]

== The speaker ==

Dave Wichers is a cofounder and the Chief Operating Officer (COO) of [http://www.aspectsecurity.com Aspect Security], a company that specializes in application security services.

As a volunteer to OWASP, Dave is:

* A member of the [[About_OWASP#Global_Board_Members|OWASP Board]],
* The [[:Category:OWASP_AppSec_Conference | OWASP Conferences]] Chair,
* Project lead and coauthor of the [[OWASP_Top_Ten_Project | OWASP Top 10]],
* Coauthor of the [[ASVS | OWASP Application Security Verification Standard]], and
* Contributor to the [[ESAPI | OWASP Enterprise Security API (ESAPI)]] project.

Dave has over 20 years of experience in the information security field, and has focused exclusively on application security since 1998. At Aspect, in addition to his COO duties, he is Aspect's application security courseware lead, one of their chief instructors, and provides a wide variety of application security consulting services to Aspect's clients. Prior to starting Aspect, he ran the Application Security Services Group at Exodus Communications. Dave has a Bachelors and Masters degree in Computer Science, is a CISSP, and a CISM.

Dave can be reached at: dave.wichers (at) aspectsecurity.com or dave.wichers (at) owasp.org

== Notes ==

'''Getting Started with the Top Ten and OWASP Guides'''
– Dave Wichers
We are still not asking for secure software. Is your customer really asking you to create secure software? There is a fundamental supply and demand problem. No one will produce something that no one wants to buy. If I spend the effort to build secure software, then it increases the cost. If it has the same functionality but has the invisible feature of security, then no one will buy it yet. We as consumers must demand security from these companies we patronize. Microsoft has worked very hard to produce secure software. Some vendors are starting to win contracts because their software is more secure.

When I work with the DISA STIGs I look at the code to see if it is secure. If I find something, they fix it. If I don’t, then they don’t fix it. They are focusing on verification. If there is enough flaws found, then they might ask if there is a better way to build security in. But if we don’t demand security then we won’t get it.

I am going to discuss half a dozen projects, but OWASP has many more in various levels of maturity. There is a bar at the top of the OWASP website that lists some of the most mature projects. The OWASP meritocracy allows members to start new projects and then gain traction.

Many are listing OWASP references in either strong or weak ways. PCI point directly to the OWASP Top 10 despite having no formal relationship. The DISA STIG makes many references to the Top 10 for more information.

'''Top 10 Web Application Security Risks'''
* Prevention Cheat Sheet Series
* Application Security Verification Standard (ASVS)
* Building Guide
* Code Review Guide
* Testing Guide
* Application Security Desk Reference (ASDR) The ASDR provides plenty of broad information about vulnerabilities.

The first step to helping developers is to make them aware of the issues. The Top 10 is a broad brush awareness document for any community. But it won’t provide all the details. If you don’t understand the technical foundation of the problems then you can’t build code to be secure against them.

The Top 10 helps developers to understand risk. Businesses must understand the risks and how significant they are. The business must understand the gravity of the ramifications if this risk is exploited. Until the business understands the risk, they won’t do anything about it.

The managers must care for the developers to care. The Top 10 includes a section stating that it is related to risk instead of just technical specifications. Businesses understand and are concerned with risk. Everything is a cost-benefit balance.

The attacks are becoming extremely professional and advanced. Economic pressures may not come as strongly from the consumers who are “path-of-least-resistance driven” but business-to-business pressure will be much stronger. This has been seen in the credit card processing industry. Google removed all of its internal Microsoft operating system installations after the Chinese hack.

The OWASP material ranges from understanding risk, to avoiding risk, to measuring risk, to managing risk.

Microsoft has statistics about the cost of the appsec program being zero or negative because the cost of rework outweighs their investment. This information is publicly available. Over time the up front cost is reduced.

The Top 10 was created in 2003. Each year it has been condensed so it is easily consumable. The Top 10 was always about risk, but making this distinction has been made clearer. Although some flaws may be less prevalent, they are just as devastating when exploited. The Top 10 is prioritized based upon the OWASP Risk Rating Methodology.

'''The OWASP Prevention Cheat Sheet''' provides article on how to avoid the most common web security problems. They are all interlinked. They include very concise guidance for developers.

;[[:Category:OWASP Application Security Verification Standard Project|OWASP Application Security Verification Standard Project]]
'''The OWASP Application Security Verification Standard (ASVS)''' provides a standard for how to verify security services. This helps organizations to compare application security service vendors. The ASVS is a positive model stating what should be found. The byproduct is a comprehensive roadmap of requirements which other OWASP ecosystems could leverage. The standard is our opinion of what should be included. The ASVS is a verification standard and is organized in terms of level of difficulty. This is why automated verification is at level 1 and design verification is at level 3.

The government needs to ask for secure software in any form. '''The OWASP Legal Guide''' facilitates the requiring of secure software in contracts. Its use would require a smart purchaser of security to require it of their vendor and having it as a factor of competitive bidding.

Q. Have any vendors adopted the legal language? A few companies have experimented with the legal language.
A. There are slide decks on each OWASP project available online.

;[[:Category:OWASP Guide Project|OWASP Development Guide]]
'''The OWASP Developer Guide''' was the original flagship document. The document has languished but there is a team that is working to update it.

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]
Developers need secure controls to build secure software. This document explains the intent of this statement. It outlines the standard set of controls needed and provides an explanation of the implementation. It outlines standard control implementation in many popular languages.

'''The OWASP Code Review Guide''' outlines approaches to code review, reporting, metrics, etc. by example within various languages. It will soon be aligned with the ASVS.

[[The OWASP Testing Guide]] may be the largest OWASP project in terms of the number of contributors. This may be the most popular guide due to the number of people trying to perform testing.

The ESAPI source code is a great example of secure code. There are plenty of other free OWASP tools online as well.

Microsoft was seeing roughly 8 – 15% of up front costs, but then saw costs drop dramatically due to efficiencies and cost avoidance. Investing in software quality can also provide a means for cost reduction which is a huge culture problem.

Startups only care about marketshare, not security. Small companies should have security as a priority as they gain a certain portion of marketshare.

Open Sources is not necessarily more secure. It varies. DHS’ HOST program and another site setup in partnership with Coverity provide feedback to open source developers.

OWASP Common Numbering project organizes the guides in the same standardized order.

;[[OWASP Secure Coding Practices - Quick Reference Guide|OWASP Secure Coding Practices - Quick Reference Guide]]

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 Getting Started

2010-10-04T21:40:25Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An overview of the OWASP Top Ten, the OWASP ASVS, and the OWASP Guides.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Dave_Wichers_2010-09_OWASP_DHS_SWA_Day_-_OWASP_Projects.pptx | Download the presentation]]

== The speaker ==

Dave Wichers is a cofounder and the Chief Operating Officer (COO) of [http://www.aspectsecurity.com Aspect Security], a company that specializes in application security services.

As a volunteer to OWASP, Dave is:

* A member of the [[About_OWASP#Global_Board_Members|OWASP Board]],
* The [[:Category:OWASP_AppSec_Conference | OWASP Conferences]] Chair,
* Project lead and coauthor of the [[OWASP_Top_Ten_Project | OWASP Top 10]],
* Coauthor of the [[ASVS | OWASP Application Security Verification Standard]], and
* Contributor to the [[ESAPI | OWASP Enterprise Security API (ESAPI)]] project.

Dave has over 20 years of experience in the information security field, and has focused exclusively on application security since 1998. At Aspect, in addition to his COO duties, he is Aspect's application security courseware lead, one of their chief instructors, and provides a wide variety of application security consulting services to Aspect's clients. Prior to starting Aspect, he ran the Application Security Services Group at Exodus Communications. Dave has a Bachelors and Masters degree in Computer Science, is a CISSP, and a CISM.

Dave can be reached at: dave.wichers (at) aspectsecurity.com or dave.wichers (at) owasp.org

== Notes ==

'''Getting Started with the Top Ten and OWASP Guides'''
– Dave Wichers
We are still not asking for secure software. Is your customer really asking you to create secure software? There is a fundamental supply and demand problem. No one will produce something that no one wants to buy. If I spend the effort to build secure software, then it increases the cost. If it has the same functionality but has the invisible feature of security, then no one will buy it yet. We as consumers must demand security from these companies we patronize. Microsoft has worked very hard to produce secure software. Some vendors are starting to win contracts because their software is more secure.

When I work with the DISA STIGs I look at the code to see if it is secure. If I find something, they fix it. If I don’t, then they don’t fix it. They are focusing on verification. If there is enough flaws found, then they might ask if there is a better way to build security in. But if we don’t demand security then we won’t get it.

I am going to discuss half a dozen projects, but OWASP has many more in various levels of maturity. There is a bar at the top of the OWASP website that lists some of the most mature projects. The OWASP meritocracy allows members to start new projects and then gain traction.

Many are listing OWASP references in either strong or weak ways. PCI point directly to the OWASP Top 10 despite having no formal relationship. The DISA STIG makes many references to the Top 10 for more information.

'''Top 10 Web Application Security Risks'''
* Prevention Cheat Sheet Series
* Application Security Verification Standard (ASVS)
* Building Guide
* Code Review Guide
* Testing Guide
* Application Security Desk Reference (ASDR) The ASDR provides plenty of broad information about vulnerabilities.

The first step to helping developers is to make them aware of the issues. The Top 10 is a broad brush awareness document for any community. But it won’t provide all the details. If you don’t understand the technical foundation of the problems then you can’t build code to be secure against them.

The Top 10 helps developers to understand risk. Businesses must understand the risks and how significant they are. The business must understand the gravity of the ramifications if this risk is exploited. Until the business understands the risk, they won’t do anything about it.

The managers must care for the developers to care. The Top 10 includes a section stating that it is related to risk instead of just technical specifications. Businesses understand and are concerned with risk. Everything is a cost-benefit balance.

The attacks are becoming extremely professional and advanced. Economic pressures may not come as strongly from the consumers who are “path-of-least-resistance driven” but business-to-business pressure will be much stronger. This has been seen in the credit card processing industry. Google removed all of its internal Microsoft operating system installations after the Chinese hack.

The OWASP material ranges from understanding risk, to avoiding risk, to measuring risk, to managing risk.

Microsoft has statistics about the cost of the appsec program being zero or negative because the cost of rework outweighs their investment. This information is publicly available. Over time the up front cost is reduced.

The Top 10 was created in 2003. Each year it has been condensed so it is easily consumable. The Top 10 was always about risk, but making this distinction has been made clearer. Although some flaws may be less prevalent, they are just as devastating when exploited. The Top 10 is prioritized based upon the OWASP Risk Rating Methodology.

'''The OWASP Prevention Cheat Sheet''' provides article on how to avoid the most common web security problems. They are all interlinked. They include very concise guidance for developers.

'''The OWASP Application Security Verification Standard (ASVS)''' provides a standard for how to verify security services. This helps organizations to compare application security service vendors. The ASVS is a positive model stating what should be found. The byproduct is a comprehensive roadmap of requirements which other OWASP ecosystems could leverage. The standard is our opinion of what should be included. The ASVS is a verification standard and is organized in terms of level of difficulty. This is why automated verification is at level 1 and design verification is at level 3.

The government needs to ask for secure software in any form. '''The OWASP Legal Guide''' facilitates the requiring of secure software in contracts. Its use would require a smart purchaser of security to require it of their vendor and having it as a factor of competitive bidding.

Q. Have any vendors adopted the legal language? A few companies have experimented with the legal language.
A. There are slide decks on each OWASP project available online.

'''The OWASP Developer Guide''' was the original flagship document. The document has languished but there is a team that is working to update it.

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]
Developers need secure controls to build secure software. This document explains the intent of this statement. It outlines the standard set of controls needed and provides an explanation of the implementation. It outlines standard control implementation in many popular languages.

'''The OWASP Code Review Guide''' outlines approaches to code review, reporting, metrics, etc. by example within various languages. It will soon be aligned with the ASVS.

[[The OWASP Testing Guide]] may be the largest OWASP project in terms of the number of contributors. This may be the most popular guide due to the number of people trying to perform testing.

The ESAPI source code is a great example of secure code. There are plenty of other free OWASP tools online as well.

Microsoft was seeing roughly 8 – 15% of up front costs, but then saw costs drop dramatically due to efficiencies and cost avoidance. Investing in software quality can also provide a means for cost reduction which is a huge culture problem.

Startups only care about marketshare, not security. Small companies should have security as a priority as they gain a certain portion of marketshare.

Open Sources is not necessarily more secure. It varies. DHS’ HOST program and another site setup in partnership with Coverity provide feedback to open source developers.

OWASP Common Numbering project organizes the guides in the same standardized order.

[[Category:OWASP_Conference_Presentations]]

OWASP Software Assurance Day DC 2010

2010-10-04T21:32:58Z

Walter Houser:

__NOTOC__
[http://www.nist.gov/itl/ssd/software-assurance-forum.cfm Register] | [http://www.nist.gov/public_affairs/maps/index.cfm Directions to NIST] | [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html 13th Semi-Annual Software Assurance Forum]
<br>
====Welcome====

Welcome to the '''OWASP Software Assurance Day DC 2010''' wiki page.

This single-day training session will be held on '''September 27th''' as a part of the '''13th Semi-Annual Software Assurance Forum''' (September 27th - October 1st) sponsored by the US Department of Homeland Security (DHS), Department of Defense (DoD) and National Institute of Standards and Technology (NIST). The event will be held at the NIST campus in Gaithersburg Maryland.

We are pleased to invite OWASP members, attendees of the Software Assurance Forum and any other interested parties to join us for this event.

At this day-long training, OWASP will be answering the questions of:
*How do I get started in formulating an application security program using OWASP tools and resources?
*What does OWASP have to offer for those interested in software assurance?
*How do I engage with OWASP to effectively realize OWASP's potential and the wealth of resources OWASP makes freely available?<br>     (This will include upcoming OWASP events and contact information for local chapters in the DC/NOVA/Maryland area)

This day is a part of the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html 13th Semi-Annual Software Assurance Forum]. '''The week-long event is free and open, but requires registration for participation in any or all days of the event, including the OWASP day on the 27th.'''

For more information about the Software Assurance Forum, please go to [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html DHS "Build Security In" site], or go to the [http://www.nist.gov/itl/ssd/software-assurance-forum.cfm NIST site for the Software Assurance Forum] to [http://www.nist.gov/itl/ssd/software-assurance-forum.cfm register].

====Location====

The OWASP Software Assurance Day DC 2010 is the first day of the DHS/DOD/NIST Software Assurance Forum at the [http://www.nist.gov/public_affairs/maps/index.cfm NIST Campus] in Gaithersburg, Maryland.

'''YOU MUST REGISTER IN ADVANCE IN ORDER TO BE ADMITTED TO THE NIST CAMPUS'''

Specific directions will be provided upon [http://www.nist.gov/itl/ssd/software-assurance-forum.cfm registration].

Further information about the area around the NIST campus is available [http://www.nist.gov/public_affairs/visitor/index.cfm here].

====Agenda====

Agenda and Presentations for 27 September 2010

{| style="width:80%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white" | September 27th, 2010
|-
| style="width:10%; background:#7B8ABD" | 08:30-08:35 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP DHS SWA Day 2010 Intro | OWASP Software Assurance Day DC Introduction]]'''
''Doug Wilson, Mandiant''
|-
| style="width:10%; background:#7B8ABD" | 08:35-09:05 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP DHS SWA Day 2010 OWASP | Intro to OWASP]]'''
''Jeff Williams, Aspect Security''
|-
| style="width:10%; background:#7B8ABD" | 09:05-10:30 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP DHS SWA Day 2010 Getting Started | Getting Started with OWASP: the Top Ten, ASVS and the Guides]]'''
''Dave Wichers, Aspect Security''
|-
| style="width:10%; background:#7B8ABD" | 10:30-11:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | '''Morning Break'''
|-
| style="width:10%; background:#7B8ABD" | 11:00-12:00 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP DHS SWA Day 2010 OpenSAMM | How to build a software assurance program with OpenSAMM]]'''
''Shakeel Tufail, Fortify''
|-
| style="width:10%; background:#7B8ABD" | 12:00-1:00 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP DHS SWA Day 2010 OWASP WTE | OWASP WTE: An Open Environment for Web Application Security]]'''
''Matt Tesauro, Trustwave''
|-
| style="width:10%; background:#7B8ABD" | 1:00-2:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | '''Lunch'''
|-
| style="width:10%; background:#7B8ABD" | 2:00-2:45 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP DHS SWA Day 2010 ESAPI | OWASP ESAPI]]'''
''Jeff Williams, Aspect Security''
|-
| style="width:10%; background:#7B8ABD" | 2:45-3:15 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | '''Afternoon Break'''
|-
| style="width:10%; background:#7B8ABD" | 3:15-4:00 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | '''[[OWASP in Action: Tools for the DISA ASD STIG]]'''
''Jason Li, Aspect Security''
|-
| style="width:10%; background:#7B8ABD" | 4:00-4:30 || colspan="2" style="width:80%; background:#F2F2F2" align="left" | Conclusion and Q&A
''Doug Wilson''
|}

====Registration====
The 13th Semi-Annual Software Assurance Forum is a free event, but no one will be admitted to the NIST campus if they have not [http://www.nist.gov/itl/ssd/software-assurance-forum.cfm registered] in advance.

Despite the fact that this is a free conference, we still need you to register to fulfill security requirements of the facility and to ensure that we don't exceed venue capacity.

====Accommodations====

NIST has recommendations for [http://www.nist.gov/public_affairs/visitor/hotels.cfm local hotels in the Gaithersburg area on their website]

====Transportation====

==By plane==
The venue area can be reached by commercial aviation through either [http://www.metwashairports.com/Dulles/ Dulles International Airport] or [http://www.mwaa.com/national/ Reagan National Airport].

Directions from local airports can be found on the NIST website: http://www.nist.gov/public_affairs/maps/directions.cfm

==Shuttle & Ground Transport==
Information about local ground transportation can be found on the NIST website: http://www.nist.gov/public_affairs/visitor/transpor.cfm

==How to get to the venue?==
See the NIST [http://www.nist.gov/public_affairs/maps/index.cfm directions and maps page].

====Contact====

For more information please contact the team below for conference details, sponsorship or registration.

'''Mr Doug Wilson (Event Organizer)''' , OWASP DC Chapter Lead, AppSec DC 2010 Organizer

Email: [mailto:doug.wilson@owasp.org doug.wilson@owasp.org]

Mobile: 301.814.1348

'''Kate Hartmann'''

OWASP Operations Director

9175 Guilford Road, Suite 300

Columbia, MD 21046, USA

Phone: +1-301-575-0189

Facsimile: +1-301-604-8033

Email: [mailto:kate.hartmann@owasp.org kate.hartmann@owasp.org]

==Conference Sponsors==

If you are interested in sponsoring this OWASP event, please contact [mailto:doug.wilson@owasp.org Doug Wilson].

<headertabs />
[[Category:OWASP AppSec Conference]]

OWASP DHS SWA Day 2010 OWASP

2010-10-04T20:33:17Z

Walter Houser:

OWASP DHS SWA Day 2010 OWASP

2010-10-04T20:32:33Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An introduction to the OWASP mission.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_OWASP.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

== Notes ==

Introduction to OWASP – Jeff Williams takes a different view of assurance. Heis trying to push the assurance view into high speed software development. Also he will explain how OWASP works and the methods used to change the world. These are ideas that can actually change the game.

“Security is a process, not a product.” If security is a process we could just follow it. Security is more like an artifact of a process; an emergent characteristic of following a procedss. We like to look at security as an eco-system.

Background – There are roughly 10 million developers writing code and about a trillion lines of code. If there were just 100 developers looking at 100 apps for 100 organizations.
* 83 apps would have a serious vulnerability
* 72 apps would have XSS
* 40 would have SQL injection
* 1 company would have responsible appsec program (rounded up)
* 1 developer would have any security training
* All applications would have code from unknown origin
* 90 apps use libraries with known unpatched holes
* 5 apps have has some sort of scan or test
* 1 app has had a manual code review (rounded up)
* There is no amount of automation that can find the problems
* 0 apps provide any visibility into security
Every website has a privacy page, but none have a security page.

How do you want the world to be? Is this acceptable? We trust this software. Software is becoming more and more complicated every day. We are connecting our architectures at an amazing rate. We trust it to do more sensitive things.

Three forces: complexity, connectivity, criticality – create a perfect storm of insecurity

What is stopping us from having assurance?
1. Trust – we trust the internet, we naturally trust software, we assume no vulnerabilities instead of the other way around of having to be proven
2. Blame – we instantly blame the developers.
3. Hide – we hide security. When developers are blamed, they hide their security measures.

These three aspects create a toxic eco-system. We have no other option than to trust due to this system.
This is a self-enforcing cycle that keeps security down.

OWASP’s mission is focused on visibility to break the cycle. OWASP is working toward a security facts label (like a food nutrition label)

There is an underlying economic principle at work. At markets where there is asymmetric information, it is very difficult for consumers to get a fair price. When you buy software you have no idea if it is a lemon so you cannot get a fair price for security. Until we fix the software market, nothing else matters. We will not get secure code out of it. See the 1970 paper by the economist George Akerlof [http://en.wikipedia.org/wiki/The_Market_for_Lemons The Market for Lemons ]. Ross Anderson’s paper [http://www.acsac.org/2001/papers/110.pdf Why Information Security Is So Hard ] also discusses the ecomonic challenges facing security practitioners.

OWASP is an eco-system. An OWASP intern started the [http://www.Pythonsecurity.org Pythonsecurity.org ] project due to a void of information. These ecosystems pull together information, a community, etc. There are builders and breakers working together for security. Security is co-evolutionary. The bad guys break in, the good guys add more defenses, repeatedly. This is the process that generates security.

Evolution of an ecosystem – individual, website, contributors, self-sustaining, etc.

OWASP is trying to bootstrap lots of ecosystems like this Python Security ecosystem. OWASP operates on a shoestring budget. It has only two full time employees. It is a 501c3 organization. OWASP just began the college chapters program. This program seeks to embed security knowledge into all colleges with computer science degrees.

OWASP offers many conferences around the world. OWASP works with industry. OWASP has a connections committee to bring together people who need to speak to each other to improve security. OWASP receives approximately 15000 page views on its website. Last week when twitter was infected with the XSS worm, there was a large spike in traffic.

The reasoning behind the agenda: start narrow with things you can use now, then expose you to ways to improve security, show you the OWASP live compact disc (CD), then move toward success stories from implementing the DISA STIG.

While consumers may not be risking a significant amount, there are companies that are losing millions of dollars per day, and this does not need to be happening.

Q. How do you get a developer passionate about security? What made the community shift toward focusing on security?

A. Developers want to do the right thing and build secure code. There is a lot for developers to learn. I don’t think we can expect developers to become security experts. We need to focus on making security easier for developers. We should take security out of their hands and put it into standards and tools. Visibility is at the core of the solution to get people focused on it and to improve.

Q. You mentioned critical infrastructure and legacy. What is OWAPS’s position on legacy systems? There must be an interim solution.

A. There has to be an interim because of the vast amount of lines of code. We need to take the same approach with new systems. Identify the risk, prioritize the risks, and then put controls in place to counter them. We become hypnotized by little problems that are revealed by tools, but we miss the larger more important risks that may not be as easy to detect.

Q. Is there a roadmap for APIs?
A. We will cover that in the ESAPI presentation.

Q. So many people think of other types of security other than application security. How can we bridge these two communities?

A. We have had challenges turning network security folks into software security folks. We have had luck with making developers more aware of software security. There is more work to be done.

Q. There is a large knowledge gap between the developers and the security folks that have never written a line of code. Could OWASP do anything to point out the knowledge gap?

A. There is no silver bullet. The solution is complex. If a new cycle of visibility and collaboration can be created, then this would make a big difference. We have an issue of many compliance and security people that are not engineers. They are analyzing artifacts without understanding the fundamental pathways of how the code works. There are no people in between the developers and the assessors. We need people who understand both to serve this intermediate position. We either need to teach security people engineering or vice versa.

When you think of software assurance, please don’t confuse all of this with verification. Verification is not application security. We should spend 80% building it right, then 10% checking, then 10% for other things.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OWASP

2010-10-04T20:25:34Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An introduction to the OWASP mission.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_OWASP.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

== Notes ==

Introduction to OWASP – Jeff Williams
I take a different view of assurance. I am trying to push the assurance view into high speed software development. I want to explain how OWASP works and the methods we use to change the world. I want to share ideas that can actually change the game.

“Security is a process, not a product.” If security is a process we could just follow it. I think security is more like an artifact of a process; an emergent characteristic of following a procedss. I like to look at security as an eco-system.

Background – There are roughly 10 million developers writing code and about a trillion lines of code. If there were just 100 developers looking at 100 apps for 100 organizations.
* 83 apps would have a serious vulnerability
* 72 apps would have XSS
* 40 would have SQL injection
* 1 company would have responsible appsec program (rounded up)
* 1 developer would have any security training
* All applications would have code from unknown origin
* 90 apps use libraries with known unpatched holes
* 5 apps have has some sort of scan or test
* 1 app has had a manual code review (rounded up)
* There is no amount of automation that can find the problems
* 0 apps provide any visibility into security
Every website has a privacy page, but none have a security page.

How do you want the world to be? Is this acceptable? We trust this software. Software is becoming more and more complicated every day. We are connecting our architectures at an amazing rate. We trust it to do more sensitive things.

Three forces: complexity, connectivity, criticality – create a perfect storm of insecurity

What is stopping us from having assurance?
1. Trust – we trust the internet, we naturally trust software, we assume no vulnerabilities instead of the other way around of having to be proven
2. Blame – we instantly blame the developers.
3. Hide – we hide security. When developers are blamed, they hide their security measures.

These three aspects create a toxic eco-system. We have no other option than to trust due to this system.
This is a self-enforcing cycle that keeps security down.

OWASP’s mission is focused on visibility to break the cycle. OWASP is working toward a security facts label (like a food nutrition label)

There is an underlying economic principle at work. At markets where there is asymmetric information, it is very difficult for consumers to get a fair price. When you buy software you have no idea if it is a lemon so you cannot get a fair price for security. Until we fix the software market, nothing else matters. We will not get secure code out of it. See the 1970 paper by the economist George Akerlof [http://en.wikipedia.org/wiki/The_Market_for_Lemons The Market for Lemons ]. Ross Anderson’s paper [http://www.acsac.org/2001/papers/110.pdf Why Information Security Is So Hard ] also discusses the ecomonic challenges facing security practitioners.

OWASP is an eco-system. An OWASP intern started the [http://www.Pythonsecurity.org Pythonsecurity.org ] project due to a void of information. These ecosystems pull together information, a community, etc. There are builders and breakers working together for security. Security is co-evolutionary. The bad guys break in, the good guys add more defenses, repeatedly. This is the process that generates security.

Evolution of an ecosystem – individual, website, contributors, self-sustaining, etc.

OWASP is trying to bootstrap lots of ecosystems like this Python Security ecosystem. OWASP operates on a shoestring budget. It has only two full time employees. It is a 501c3 organization. OWASP just began the college chapters program. This program seeks to embed security knowledge into all colleges with computer science degrees.

OWASP offers many conferences around the world. OWASP works with industry. OWASP has a connections committee to bring together people who need to speak to each other to improve security. OWASP receives approximately 15000 page views on its website. Last week when twitter was infected with the XSS worm, there was a large spike in traffic.

The reasoning behind the agenda: start narrow with things you can use now, then expose you to ways to improve security, show you the OWASP live compact disc (CD), then move toward success stories from implementing the DISA STIG.

While consumers may not be risking a significant amount, there are companies that are losing millions of dollars per day, and this does not need to be happening.

Q. How do you get a developer passionate about security? What made the community shift toward focusing on security?

A. Developers want to do the right thing and build secure code. There is a lot for developers to learn. I don’t think we can expect developers to become security experts. We need to focus on making security easier for developers. We should take security out of their hands and put it into standards and tools. Visibility is at the core of the solution to get people focused on it and to improve.

Q. You mentioned critical infrastructure and legacy. What is OWAPS’s position on legacy systems? There must be an interim solution.

A. There has to be an interim because of the vast amount of lines of code. We need to take the same approach with new systems. Identify the risk, prioritize the risks, and then put controls in place to counter them. We become hypnotized by little problems that are revealed by tools, but we miss the larger more important risks that may not be as easy to detect.

Q. Is there a roadmap for APIs?
A. We will cover that in the ESAPI presentation.

Q. So many people think of other types of security other than application security. How can we bridge these two communities?

A. We have had challenges turning network security folks into software security folks. We have had luck with making developers more aware of software security. There is more work to be done.

Q. There is a large knowledge gap between the developers and the security folks that have never written a line of code. Could OWASP do anything to point out the knowledge gap?

A. There is no silver bullet. The solution is complex. If a new cycle of visibility and collaboration can be created, then this would make a big difference. We have an issue of many compliance and security people that are not engineers. They are analyzing artifacts without understanding the fundamental pathways of how the code works. There are no people in between the developers and the assessors. We need people who understand both to serve this intermediate position. We either need to teach security people engineering or vice versa.

When you think of software assurance, please don’t confuse all of this with verification. Verification is not application security. We should spend 80% building it right, then 10% checking, then 10% for other things.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OWASP

2010-10-04T20:24:50Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An introduction to the OWASP mission.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_OWASP.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

== Notes ==

Introduction to OWASP – Jeff Williams
I take a different view of assurance. I am trying to push the assurance view into high speed software development. I want to explain how OWASP works and the methods we use to change the world. I want to share ideas that can actually change the game.

“Security is a process, not a product.” If security is a process we could just follow it. I think security is more like an artifact of a process; an emergent characteristic of following a procedss. I like to look at security as an eco-system.

Background – There are roughly 10 million developers writing code and about a trillion lines of code. If there were just 100 developers looking at 100 apps for 100 organizations.
* 83 apps would have a serious vulnerability
* 72 apps would have XSS
* 40 would have SQL injection
* 1 company would have responsible appsec program (rounded up)
* 1 developer would have any security training
* All applications would have code from unknown origin
* 90 apps use libraries with known unpatched holes
* 5 apps have has some sort of scan or test
* 1 app has had a manual code review (rounded up)
* There is no amount of automation that can find the problems
* 0 apps provide any visibility into security
Every website has a privacy page, but none have a security page.

How do you want the world to be? Is this acceptable? We trust this software. Software is becoming more and more complicated every day. We are connecting our architectures at an amazing rate. We trust it to do more sensitive things.

Three forces: complexity, connectivity, criticality – create a perfect storm of insecurity

What is stopping us from having assurance?
1. Trust – we trust the internet, we naturally trust software, we assume no vulnerabilities instead of the other way around of having to be proven
2. Blame – we instantly blame the developers.
3. Hide – we hide security. When developers are blamed, they hide their security measures.

These three aspects create a toxic eco-system. We have no other option than to trust due to this system.
This is a self-enforcing cycle that keeps security down.

OWASP’s mission is focused on visibility to break the cycle. OWASP is working toward a security facts label (like a food nutrition label)

There is an underlying economic principle at work. At markets where there is asymmetric information, it is very difficult for consumers to get a fair price. When you buy software you have no idea if it is a lemon so you cannot get a fair price for security. Until we fix the software market, nothing else matters. We will not get secure code out of it. See 1970 paper by the economist George Akerlof [http://en.wikipedia.org/wiki/The_Market_for_Lemons The Market for Lemons ]. Ross Anderson’s paper [http://www.acsac.org/2001/papers/110.pdf Why Information Security Is So Hard ] also discusses the ecomonic challenges facing security practitioners.

OWASP is an eco-system. An OWASP intern started the [http://www.Pythonsecurity.org Pythonsecurity.org ] project due to a void of information. These ecosystems pull together information, a community, etc. There are builders and breakers working together for security. Security is co-evolutionary. The bad guys break in, the good guys add more defenses, repeatedly. This is the process that generates security.

Evolution of an ecosystem – individual, website, contributors, self-sustaining, etc.

OWASP is trying to bootstrap lots of ecosystems like this Python Security ecosystem. OWASP operates on a shoestring budget. It has only two full time employees. It is a 501c3 organization. OWASP just began the college chapters program. This program seeks to embed security knowledge into all colleges with computer science degrees.

OWASP offers many conferences around the world. OWASP works with industry. OWASP has a connections committee to bring together people who need to speak to each other to improve security. OWASP receives approximately 15000 page views on its website. Last week when twitter was infected with the XSS worm, there was a large spike in traffic.

The reasoning behind the agenda: start narrow with things you can use now, then expose you to ways to improve security, show you the OWASP live compact disc (CD), then move toward success stories from implementing the DISA STIG.

While consumers may not be risking a significant amount, there are companies that are losing millions of dollars per day, and this does not need to be happening.

Q. How do you get a developer passionate about security? What made the community shift toward focusing on security?

A. Developers want to do the right thing and build secure code. There is a lot for developers to learn. I don’t think we can expect developers to become security experts. We need to focus on making security easier for developers. We should take security out of their hands and put it into standards and tools. Visibility is at the core of the solution to get people focused on it and to improve.

Q. You mentioned critical infrastructure and legacy. What is OWAPS’s position on legacy systems? There must be an interim solution.

A. There has to be an interim because of the vast amount of lines of code. We need to take the same approach with new systems. Identify the risk, prioritize the risks, and then put controls in place to counter them. We become hypnotized by little problems that are revealed by tools, but we miss the larger more important risks that may not be as easy to detect.

Q. Is there a roadmap for APIs?
A. We will cover that in the ESAPI presentation.

Q. So many people think of other types of security other than application security. How can we bridge these two communities?

A. We have had challenges turning network security folks into software security folks. We have had luck with making developers more aware of software security. There is more work to be done.

Q. There is a large knowledge gap between the developers and the security folks that have never written a line of code. Could OWASP do anything to point out the knowledge gap?

A. There is no silver bullet. The solution is complex. If a new cycle of visibility and collaboration can be created, then this would make a big difference. We have an issue of many compliance and security people that are not engineers. They are analyzing artifacts without understanding the fundamental pathways of how the code works. There are no people in between the developers and the assessors. We need people who understand both to serve this intermediate position. We either need to teach security people engineering or vice versa.

When you think of software assurance, please don’t confuse all of this with verification. Verification is not application security. We should spend 80% building it right, then 10% checking, then 10% for other things.

[[Category:OWASP_Conference_Presentations]]

OWASP DHS SWA Day 2010 OWASP

2010-10-04T20:23:26Z

Walter Houser:

== The presentation ==

[[Image:Owasp_logo_normal.jpg|right]]An introduction to the OWASP mission.

This presentation is given as part of [[OWASP Software Assurance Day DC 2010 | OWASP Software Assurance Day]] at the [https://buildsecurityin.us-cert.gov/bsi/events/1133-BSI.html | 13th Annual Software Assurance Forum].

[[Media:Jeff_Williams_2010-09_OWASP_DHS_SWA_Day_-_OWASP.pptx | Download the presentation]]

== The speaker ==

Jeff Williams is the founder and CEO of Aspect Security, specializing exclusively in application security professional services. Jeff also serves as the volunteer Chair of the Open Web Application Security Project (OWASP). He has made extensive contributions to the application security community through OWASP, including writing the Top Ten, WebGoat, Secure Software Contract Annex, Enterprise Security API, OWASP Risk Rating Methodology, and starting the worldwide local chapters program. If nothing else, Jeff is probably the tallest application security expert in the world and likes nothing better than discussing new ideas for changing the way we build software.

== Notes ==

Introduction to OWASP – Jeff Williams
I take a different view of assurance. I am trying to push the assurance view into high speed software development. I want to explain how OWASP works and the methods we use to change the world. I want to share ideas that can actually change the game.

“Security is a process, not a product.” If security is a process we could just follow it. I think security is more like an artifact of a process; an emergent characteristic of following a procedss. I like to look at security as an eco-system.

Background – There are roughly 10 million developers writing code and about a trillion lines of code. If there were just 100 developers looking at 100 apps for 100 organizations.
* 83 apps would have a serious vulnerability
* 72 apps would have XSS
* 40 would have SQL injection
* 1 company would have responsible appsec program (rounded up)
* 1 developer would have any security training
* All applications would have code from unknown origin
* 90 apps use libraries with known unpatched holes
* 5 apps have has some sort of scan or test
* 1 app has had a manual code review (rounded up)
* There is no amount of automation that can find the problems
* 0 apps provide any visibility into security
Every website has a privacy page, but none have a security page.

How do you want the world to be? Is this acceptable? We trust this software. Software is becoming more and more complicated every day. We are connecting our architectures at an amazing rate. We trust it to do more sensitive things.

Three forces: complexity, connectivity, criticality – create a perfect storm of insecurity

What is stopping us from having assurance?
1. Trust – we trust the internet, we naturally trust software, we assume no vulnerabilities instead of the other way around of having to be proven
2. Blame – we instantly blame the developers.
3. Hide – we hide security. When developers are blamed, they hide their security measures.

These three aspects create a toxic eco-system. We have no other option than to trust due to this system.
This is a self-enforcing cycle that keeps security down.

OWASP’s mission is focused on visibility to break the cycle. OWASP is working toward a security facts label (like a food nutrition label)

There is an underlying economic principle at work. At markets where there is asymmetric information, it is very difficult for consumers to get a fair price. When you buy software you have no idea if it is a lemon so you cannot get a fair price for security. Until we fix the software market, nothing else matters. We will not get secure code out of it. See 1970 paper by the economist George Akerlof [The Market for Lemons http://en.wikipedia.org/wiki/The_Market_for_Lemons]. Ross Anderson’s paper [http://www.acsac.org/2001/papers/110.pdf Why Information Security Is So Hard ] also discusses the ecomonic challenges facing security practitioners.

OWASP is an eco-system. An OWASP intern started the [Pythonsecurity.org http://www.Pythonsecurity.org] project due to a void of information. These ecosystems pull together information, a community, etc. There are builders and breakers working together for security. Security is co-evolutionary. The bad guys break in, the good guys add more defenses, repeatedly. This is the process that generates security.

Evolution of an ecosystem – individual, website, contributors, self-sustaining, etc.

OWASP is trying to bootstrap lots of ecosystems like this Python Security ecosystem. OWASP operates on a shoestring budget. It has only two full time employees. It is a 501c3 organization. OWASP just began the college chapters program. This program seeks to embed security knowledge into all colleges with computer science degrees.

OWASP offers many conferences around the world. OWASP works with industry. OWASP has a connections committee to bring together people who need to speak to each other to improve security. OWASP receives approximately 15000 page views on its website. Last week when twitter was infected with the XSS worm, there was a large spike in traffic.

The reasoning behind the agenda: start narrow with things you can use now, then expose you to ways to improve security, show you the OWASP live compact disc (CD), then move toward success stories from implementing the DISA STIG.

While consumers may not be risking a significant amount, there are companies that are losing millions of dollars per day, and this does not need to be happening.

Q. How do you get a developer passionate about security? What made the community shift toward focusing on security?

A. Developers want to do the right thing and build secure code. There is a lot for developers to learn. I don’t think we can expect developers to become security experts. We need to focus on making security easier for developers. We should take security out of their hands and put it into standards and tools. Visibility is at the core of the solution to get people focused on it and to improve.

Q. You mentioned critical infrastructure and legacy. What is OWAPS’s position on legacy systems? There must be an interim solution.

A. There has to be an interim because of the vast amount of lines of code. We need to take the same approach with new systems. Identify the risk, prioritize the risks, and then put controls in place to counter them. We become hypnotized by little problems that are revealed by tools, but we miss the larger more important risks that may not be as easy to detect.

Q. Is there a roadmap for APIs?
A. We will cover that in the ESAPI presentation.

Q. So many people think of other types of security other than application security. How can we bridge these two communities?

A. We have had challenges turning network security folks into software security folks. We have had luck with making developers more aware of software security. There is more work to be done.

Q. There is a large knowledge gap between the developers and the security folks that have never written a line of code. Could OWASP do anything to point out the knowledge gap?

A. There is no silver bullet. The solution is complex. If a new cycle of visibility and collaboration can be created, then this would make a big difference. We have an issue of many compliance and security people that are not engineers. They are analyzing artifacts without understanding the fundamental pathways of how the code works. There are no people in between the developers and the assessors. We need people who understand both to serve this intermediate position. We either need to teach security people engineering or vice versa.

When you think of software assurance, please don’t confuse all of this with verification. Verification is not application security. We should spend 80% building it right, then 10% checking, then 10% for other things.

[[Category:OWASP_Conference_Presentations]]