Someone on a local Slack group was looking for security conferences where they could present. Prompted by this, I went looking for a good list, and because I couldn’t find one, I created one!
Here’s my list of high-quality conferences where I’ve attended, presented, or would submit to in the future. This list is tailored towards cybersecurity professionals, and excludes academic conferences.
Minnesota
There are two notable security conferences in Minnesota, Secure360 and the Cybersecurity Summit.
Secure360: a strong regional conference held in May, currently at the conference center at Mystic Lake in Prior Lake. It’s been held for almost 20 years and was formed when the local chapters of security professional associations banded together to put on a conference (ISSA, ASIS, BCPA, ISFA, ISACA). (A photo of my 2024 talk, Security Differently is the top center photo here)
Cybersecurity Summit: the other major security conference in MN, held in October, now in its 14th year. It was started by the University of MN in partnership with MN-based corporations, other academic institutions, and government partners.
SiRA
As a SiRA member and former board member, SiRAcon gets a special mention.
SiRAcon: the annual conference of SiRA, the Society of Information Risk Analysts. SiRA was started in Minnesota, but now has a national and international reach. SiRA focuses on risk quantification and improving the practice of risk analysis applied to cybersecurity and technology. SiRAcon has no set date, and was last held August 20-22, 2024. SiRA members have access to recordings of past conferences.
USA
There are several US-based cybersecurity conferences, including the most well-known (RSA and BlackHat / DEFCON), as well as national conferences for professional associations. Many have additional venues outside the US:
RSA Conference USA: AFAIK, the largest security conference in the world, held annually in San Francisco in May. It’s expensive and highly competitive for talk submissions.
Black Hat USA and DEFCON: DEFCON was the original “Hacker” conference first held in Las Vegas in 1993. Black Hat started in 1997 as the “corporate” version of DEFCON. Both are held back to back in Las Vegas in August.
Security BSides: a loosely affiliated group of conferences, originally started to feature talks rejected from Black Hat, and later RSA. BSidesSF and BSidesLV are held roughly concurrently with the main conferences (RSA, Black Hat).
OWASP Global AppSec: Originally AppSec USA, OWASP hosts a global Application Security focused conference in the fall (September 2024 and November in 2025 and 2026).
ISC2 Security Congress: the annual conference held by ISC2, which is best known for creating the CISSP certification, held in October.
ISACA North America: the US-based conference of ISACA, which covers both security audit (CISA) and security management (CISM), held in May.
Canada
There are two Canadian conferences I’ve attended - each only once, but both were high quality.
CanSecWest - held in Vancouver in March, a highly technical conference, and the originators of the Pwn2Own contest.
SecTor - originally an independent conference held in Toronto, it is now associated with Black Hat and in its 18th year.
The last “security” talk I’m cataloging this week is one that Sean Scott and I gave in some form a few times, based on Sean’s work to measure the effectiveness of our Application Security Team.
From the abstract:
How do you measure the effectiveness of security? How can you prove that security is a good investment?
In 2016, we established a security function within software engineering at Express Scripts. Taking a software engineering approach to security, we created testing services, hired developers to build tools and conduct secure code reviews, and established the AppSec Defenders training program.
In 2020, we challenged ourselves to evaluate the effectiveness of our application security program by analyzing the impact of our team’s services on pen-test findings. A 3-month data analysis found that development teams working with us fixed their pen-test findings faster and had significantly fewer new pen-test findings than teams we didn’t work with. We continued the analysis with a randomized controlled trial: by assigning new teams to work with us (or not), we have created an experiment to test the impact of our program.
We will share the specific application security practices that we believe led to these improved outcomes, how we adjusted our services in response to our findings, a recently published industry report that supports our conclusions, and the current status of our randomized controlled trial, which we expect to complete in the first half of 2021.
Results
This was an ambitious project, and we worked hard to create a rigorous study, grounded in evidence. There were a few key findings:
There was a significant improvement in the performance of the development teams we worked with, which we expected. The magnitude of the impact was large enough that we estimated we more than paid for our entire team with just the reduction in time spent fixing bugs after the fact, without considering the reduction in security risk.
Surprisingly, the level of engagement with our team had much less impact than whether or not a development team was working with us. We used this insight to scale back the amount of time we spent working with individual teams in order to work with a greater number of teams, to increase our overall impact.
Our strategies: using DAST + SAST, frequent scanning, and integrating SAST with our CI/CD pipeline for a steady scan cadence, were found to be the top 4 factors in improving remediation times by the Cyentia/Veracode State of Software Security Volume 11 report. This was quite validating for us, as we had taken this approach before the data was available.
Presentations
We presented the talk on four different occasions, all virtual due to the pandemic:
In August 2020, I gave a brief presentation based on our work at the SIRAcon Day 2 lightning round (Slides).
Later in 2020, we gave the full presentation at an internal company technical conference. One attendee suggested we present at an external security conference, so we did!
In May 2021, we presented together at Secure360. Slides from that event are here.
Finally, in October 2021, we presented again at the ISC2 Security Congress, with a few new slides, copy here.
Note: the SIRAcon video is only available to SIRA members.
A Footnote
Finally, a footnote: this work was inspired in part by an earlier study we performed, where we measured the impact of static code analysis scanning on security bugs in software. What we found was that simply giving teams the tool or SAST reports didn’t reduce the number of security bugs. Making SAST testing “high” failures break the builds (which we encouraged teams to adopt voluntarily) or pushing teams to resolve open high findings (which was less voluntary) was necessary for improvement, as we later showed.
As mentioned in my last post, I’ve been cataloging my past talks and am posting the “missing” ones here.
Back in 2018, I spoke at Secure360 on “Integrating Security into Emerging DevOps”. This was a brand new talk, based on my experiences from my first three years running Application Security at Express Scripts:
Imagine building a software security practice. Now imagine building a security practice while your organization is modernizing software engineering, shifting from Waterfall to modern Agile/CI/DevOps.
Teams are excited. Agile means more freedom, less bureaucracy, less security. Security rules are blockers; they are preventing software from being written and deployed, and are problems to be removed. The security team resists, worrying that agile will mean only that security bugs are pushed into production faster.
In fact, modern software engineering and security are entirely compatible; the rigor and discipline that comes with DevOps supports strong security. The challenge is that security must evolve as the organization evolves, and must be part of the natural flow of how engineers develop software today.
This session will present solutions for building security in to a modern software engineering organization that reduce friction, making the engineers happy, and reduce security issues, making the security team happy. By understanding the motivation and habits of software engineers, we can design security controls that satisfy both groups.
I’ve been meaning to post this talk for some time, as it was well received and a good case study on integrating security into a software engineering practice. Much like when Herbie Hancock hired funk musicians to play Jazz on his fusion album Head Hunters, we hired people with a software engineering background to do security; our security engineers were developers, and our application security testing team had a QA background. In this way, we were able to extend the software engineering practice into security and avoid much of the conflict that can occur when staffing AppSec with traditional security professionals.
