# Kerr Ventures — everything, in full Source: https://kerrsecure.com Generated at build time. The counts below are computed from the same data the pages render, so they cannot drift from what the site shows. Contents: 45 essays in full, 25 talks across 58 deliveries, 10 workshops, 4 chairing roles, 39 guest appearances, and three podcasts. Kerr Ventures is Chris and Deb Romeo. They founded Security Journey in 2016, bootstrapped it with no outside capital, and sold it to Level Equity in 2022 at twenty-seven employees. They did it again with Devici, acquired by Security Compass in 2025. Before Security Journey, Chris was Chief Security Advocate at Cisco. The business today is application security consulting, angel investing, and incubation. Attribution: please credit Chris Romeo and link the page the material came from. --- ## Essays 45 essays, complete. Each is also at its own URL, which is the one WordPress served it from and will not move. ### The API is the Heart of the Modern Web - URL: https://kerrsecure.com/2023/08/04/the-api-is-the-heart-of-the-modern-web-2/ - Published: 2023-08-04 - Subject: Testing & Tooling - Author: Chris Romeo As I reflect on the release of the new OWASP API Security Top Ten and its new categories, it strikes me that the API is the heart of the modern web. In a conversation within this week’s Application Security Podcast episode with Steve Wilson, we discussed how LLM/AI applications are accessed using standard web applications with backend APIs. The AI tech stack has fancy LLMs behind the scenes, but the modern web is the front door. Glancing at one of the new items, “API3:2023 - Broken Object Property Level Authorization,” we see that it combines two issues from the 2019 list: Excessive Data Exposure and Mass Assignment. The API endpoint exposes properties of an object considered sensitive and should not be read by the user, previously named: "Excessive Data Exposure" This one is simple for me — the API endpoint is spewing extra data. Think of a scenario where you call toJSON() without carefully considering the properties of an object. You now get extra properties from the object exposed to the client side. Now attackers have gained knowledge of application internals and can attempt to manipulate them via the most poorly named concept in AppSec: Mass Assignment. The API endpoint allows a user to change, add/or delete the value of a sensitive object's property which the user should not be able to access, or Mass Assignment. I don’t know where the “Mass” is coming from. I get the assignment. Perhaps we call it an Unauthorized Assignment or Private Value Assignment? 🤔 Give the new API Top Ten a read, and share it with your development teams. They need to know what has changed. Internalize it, and share it with them. --- ### Guard rails and paved roads 🛣️ - URL: https://kerrsecure.com/2023/07/28/guard-rails-and-paved-roads-🛣️-2/ - Published: 2023-07-28 - Subject: AppSec Programs & Practice - Author: Chris Romeo Guard rails and paved roads -- how do they fit together in application security? Guardrails are security tools in the pipeline that help ensure the software doesn't drift too far from established standards. These guardrails allow developers to maintain their creativity and flexibility while building features that ultimately go to the customer. Guardrails do not dictate precisely how something is done but instead provide a container around the solution and ensure that the finished feature doesn’t stray into the land of insecurity. Paved roads are platforms that developers can build on top of without having to worry about aspects like identity and access management. Paved roads and guardrails funnel developer activity without breaking their freedom to do what they need to do. Paved roads could include vetted libraries or tools without the need for admin rights inside cloud platforms. Paved roads enable developers to work with the best security features and functionality in a way that is easier for them and saves them time. Guardrails and paved roads fit together nicely in a modern application security program. Anna Weselius’s talk from RSA 2023, [Construction Time Again: A Lesson in Paving Paths for Security](https://web.archive.org/web/20230904002819/https://www.rsaconference.com/library/presentation/usa/2023/Construction%20Time%20Again%20A%20Lesson%20in%20Paving%20Paths%20for%20Security?utm_source=appsec.beehiiv.com&utm_medium=referral&utm_campaign=reasonable-appsec-6-five-security-articles-guard-rails-paved-roads-photo-and-podcast-corner), is an excellent reference to see this come together. --- ### Doing AppSec Wrong 🤦‍♂️ - URL: https://kerrsecure.com/2023/07/05/doing-appsec-wrong-🤦♂️/ - Published: 2023-07-05 - Subject: AppSec Programs & Practice - Author: Chris Romeo I spoke with a chap about AppSec, and he shared a story of a team he worked with as a Product Manager. This company’s security efforts were focused on compliance and risk management, not a pure play AppSec. He shared that when the Security team would find something, they would reach out to Product Management, declare the issue, and then say nothing. When pressed for assistance in mitigating the issue, they would hear the joyous sound of crickets 🦗on a summer evening. The Security team had no insight or wisdom to share, leaving them to flounder. I guess that this happens more than I would like to imagine. I think about the better-case scenario when advising development teams from security. I think of AppSec as a glorified coaching service, where our role is to identify the issues and solve the problem. As I’m finding is often the case, I’m living in a purist world and need more insights from the real world. I need to understand more about what is happening in AppSec. I like to think of my approach as reasonable application security, but I guess that reasonable in my mind is not what is often deployed in the real world. Embrace security coaching — find a way to add it to your AppSec program offering. The value of coaching pays off tenfold, as coaches teach, and the students take the knowledge and reflect it to others. The students become the teachers, and your security architecture and implementation gain the benefit. --- ### Simple software security: do we ask too much of developers? - URL: https://kerrsecure.com/2023/07/05/simple-software-security-do-we-ask-too-much-of-developers/ - Published: 2023-07-05 - Subject: Developers & Security Culture - Author: Chris Romeo As security professionals, we recognize software security's crucial role in protecting sensitive data, maintaining user trust in applications, and ensuring the overall safety of the software landscape. However, with the ever-evolving threat landscape and growing sophistication of cyber attacks, even seemingly minor security gaps can have significant consequences. Developers are asked to do a lot. Unfortunately, most developers have had no formal security education throughout their schooling. If a developer has security experience, it's often self-taught. Security champion programs provide a mechanism to build developers up in security, but most are new and are in the process of bestowing security knowledge and experience. This blog post is a simple idea and a simple command. What if we had to limit the software security guidance we could offer developers to a simple list of five things? (Caveat -- as an author, I understand that many more things are required for success. Please accompany me on this thought experiment, constraining us to only five items.) 1. Input Validation and Sanitization: Always validate and sanitize user input to ensure your application accepts only the expected data. This helps prevent common security vulnerabilities like SQL injection and cross-site scripting (XSS). 2. Keep Dependencies Updated: Regularly update all libraries, frameworks, and third-party components to their latest versions. This ensures that your application benefits from the latest security patches and reduces the risk of known vulnerabilities. 3. Implement Secure Authentication and Authorization: Enforce strong passwords, and enable multi-factor authentication (MFA) for all user and admin access. Implement attribute-based access control, and enforce user and object-level access control. Strong authentication controls on who can enter the system and robust access control constrain what data users can access. 4. Store Sensitive Data Securely: Encrypt sensitive data in transit and at rest using appropriate encryption techniques and securely manage encryption keys. This ensures that sensitive information is protected from unauthorized access and data breaches. 5. Follow the Principle of Least Privilege: Limit user and application permissions to the minimum necessary for performing tasks. By granting the least privilege, you reduce the potential damage in case of a security breach. What do you think? Would you add anything to this list, knowing you must delete something first? --- ### Does Anyone Need DAST? - URL: https://kerrsecure.com/2023/05/21/does-anyone-need-dast/ - Published: 2023-05-21 - Subject: Testing & Tooling - Author: Chris Romeo We did [an episode](https://securitytable.buzzsprout.com/2094080/12748343-reasonable-software-security-do-we-really-need-dast?utm_source=appsec.beehiiv.com&utm_medium=newsletter&utm_campaign=reasonable-appsec-3-does-anyone-need-dast-five-security-articles-photo-and-podcast-corner) of [AI Security Table (formerly The Security Table)](https://securitytable.ai/) a few weeks ago addressing DAST. The premise was exploring reasonable application security. (Note, this is how I got to the name of this newsletter.) I brought this to the table because I don’t believe DAST is reasonable. I did not raise my hand to signal I think anyone needs DAST. In case you don’t know, DAST is Dynamic Application Security Testing. DAST is a tool that scans a running version of your application and attempts to deduce various vulnerabilities from the [OWASP](https://owasp.org) Top Ten to multiple challenges with running versions of the services, whether API or web server. I’ve come to believe that DAST is not necessary for three reasons. First, DAST does not operate at the speed of DevOps. If DAST could scan the changes of a single Pull Request, I would be ready to believe in it. But the lack of a single change means that DAST does not run well in a pipeline. DAST requires tens of minutes to hours to thoroughly scan an application. It doesn’t run fast enough. Secondly, the results I’ve seen come out of it are limited in value. DAST is excellent at identifying missing headers or an open port, but the results I’ve seen pop out are limited. Third, and setting my context, when you deploy an application in a container with a limited container definition, a solid, mature web-based JavaScript framework running in a Kubernetes cluster within a cloud provider, there are not many findings that are even possible. By limiting the scope of the running application, I’ve already removed many of the possible things that a DAST could find. Perhaps I’m using the wrong tool — maybe I don’t know how to configure DAST properly. Perhaps, perhaps. I don’t see the value proposition. My practitioner recommendation is SAST and SCA in the pipeline and RASP in the runtime engine. I’ve used this AppSec cocktail multiple times and have had excellent results with the combo. I add DAST only when the procurement/security teams twist my arm and say they won’t buy unless we have DAST. Feel free to respond if I’m missing something, and let’s take the conversation to the public square and hash it out. This article first appeared in my weekly Application Security Newsletter, [Reasonable Application Security](https://appsec.beehiiv.com/). Please [subscribe](https://appsec.beehiiv.com/subscribe). --- ### How to get started in cybersecurity - URL: https://kerrsecure.com/2023/02/07/how-to-get-started-in-cybersecurity/ - Published: 2023-02-07 - Subject: Developers & Security Culture - Author: Chris Romeo I've been in cybersecurity for 25+ years, and the most popular question I get is my recommendation for how people can get started. Here are six things that have impacted my career and helped me grow as a security person and a human being. 1. **Get a solid understanding of systems and networks.** Systems and networks are the foundation for everything we do in security. If you want to be better at security, you must have a foundation in TCP/IP. Both on the theoretical side and on the application side. The easiest way to get this experience is to become a systems administrator. The lessons I learned as a sysadmin allow me to speak about things in security, such as DNS, that I would only be talking about theory if I hadn't ever wrestled with. Since I've had my hands on a DNS server and configured zones, I truly understand the security challenges of DNS. 2. **If you don't have Virtual Box installed on your laptop, do it now**. Virtual machines are your friend. You can configure different machines (Windows, Linux, etc.) with virtualization and connect them. You can practice with the best security distributions (Kali, Web Security Dojo, etc.) without getting arrested! Learn to use Virtual Box (open source, by the way) and build VMs to test things and learn how they work. **Have a system administrator mindset.** 3. **Read like crazy**. In the security business, things are always changing. Whether new technologies (zero trust is the hot thing now) or new techniques, this industry is not stagnant. To get ahead in any industry, you must continue to grow and learn. Become an avid reader, and learn from the books you read. Even though college is over, take notes about the things that catch you in the book, and act upon them. Do not think you must limit yourself to non-fiction. Sprinkle fiction in as well to expand your mind. 4. **Learn to code in a minimum of one language.** Code is the foundation of everything in security. Learn at least one object-oriented programming language proficiently. You'll be amazed at how you can apply the knowledge of a single language to any other language. 5. **Take advantage of the training resources available on the Internet**. There are many free security courses and training opportunities from Universities (Stanford and MIT), YouTube, where all the local conferences are archived, and Codecademy. Take advantage of the content that is out there and learn from it. Pick a specific topic and focus on it for a month. If you know nothing about Javascript, then learn it. You do not need the proficiency of someone who builds web applications daily, but knowledge can be applied when the situation arises. 6. **Network**, and not in a cheesy walk around and hand out business cards way. Make friends in the security industry. Do this on Twitter or Mastadon. Do not use Twitter as a news feed. Respond to security people and get into conversations. The worst thing that happens is that they ignore you. Go to conferences, and don't just stand in the back of the room like you are at a middle school dance. Introduce yourself to people, talk before the sessions start, and make yourself a part of the community. You'll benefit greatly from the relationships you establish with real security people. --- ### Security utility or what we all really want - URL: https://kerrsecure.com/2023/01/21/security-utility-or-what-we-all-really-want/ - Published: 2023-01-21 - Subject: AppSec Programs & Practice - Author: Chris Romeo On a recent [podcast episode of AI Security Table (formerly The Security Table)](https://securitytable.buzzsprout.com/2094080/12041838-lastpass-and-the-security-of-security-products), the gang and I discussed the Lastpass breach and the impact of security products as utilities. We spent time unpacking the concept of a security utility. A security utility is like a municipal utility, say, your water service. You have expectations of your water service. You expect that water is available on the line as long as you regularly pay your bill. When you lift the faucet or turn on the washing machine, you expect water to come out. A security utility is much the same -- a security service that you rely upon to enhance your security stance and one that you expect to always work. You can also think of it as a product or service that, if it fails, results in the breakdown of your approach to securing your digital footprints. This discussion caused me to think deeper about the expectations of a security utility. It came down to three primary categories: 1. Secure by default and in every situation. - When purchasing a security utility, expect that its creators have thought about security from every angle and in every situation. In the example of a password manager, expect that passwords will be securely stored in the cloud so that only the owner can access the passwords. Secured in such a way that the provider cannot even access the passwords. 2. Simple to install/administer. - Security utility should be simple. Of course, simple is always more secure than complex, but in this case, with security utility, end-users don't want to spend time "figuring the service out." This leads to the final category. 3. Always works without any thought. - Security utility should always work. Consumers don't want to think about how a security product or service will work; they expect it will always work. That is the beauty of the solution -- you don't have to think about it; it is always there, always protecting you. All of this to say, I had a personal experience where utility, and to some degree security utility, came into play. I built my home Wifi network using Ubiquiti gear a few years ago. I had a Wireless Controller, six access points distributed around the property, and a PoE switch that fed the access points. What I also had was a significant amount of complexity. I added a 48-port PoE switch to work in additional wired connections, which broke the setup. The network was down a few times over a month, and I spent hours troubleshooting a phantom problem where devices would appear and disappear. When they disappeared, they stopped functioning but would reappear minutes later as if nothing had happened. I decided to adopt a utility approach, and I ripped out all this complex gear and replaced it with a mesh Wifi solution. Instead of multiple layers of network and security devices, my Wifi is now the gateway to my home network. I now have a solution that is secure by default, simple to work with, and always works, with no troubleshooting by me. As folks who build products embrace the idea of security utility, anything you build should strive to become a security utility, easy to use by those who gain value from it, with minimum effort required to make it all work. --- ### Looking back and forward on a twenty-five-year career in cyber security - URL: https://kerrsecure.com/2023/01/08/looking-back-and-forward-on-a-twenty-five-year-career-in-cyber-security/ - Published: 2023-01-08 - Subject: The Security Journey Years - Author: Chris Romeo I got into security almost by accident. After graduating from university, my wife and I moved to Northern Virginia in 1997. There, I attended a job fair at a hotel. Standing in line to meet with a large government contractor, I investigated a room to my left, off the hallway. I saw a guy sitting, typing on a laptop, and talking to nobody. I thought, “Huh, this line will be here when I get back; let me see what this guy is up to.” I walked up to him and struck up a conversation. And just like that, I met Mike Weidner. During the conversation, Mike explained how they were looking for a system administrator, and I began the interview process then and there. After some follow-on interviews at their offices at Boone Blvd in Tysons Corner, Virginia, I was offered the job. Keep in mind that I had no idea what a “security” company did, but there I was. The next few years were incredible, as I was transformed from a system administrator into a security engineer. I stood on the shoulders of giants in the industry, learning from Marv Schaefer, Gary Grossman, Chuck Pfleeger, Victoria Thompson, Stan Wisseman, Bill Wilson, and many others. They taught me the true meaning of threats and how threats manifest in different pieces of a system. I worked alongside people who have grown into giants in the industry— Doug Landoll, Diann Carpenter, Jeff Williams, and Klayton Monroe. They pushed me to keep up and learn everything thrown my way. My **first big takeaway** from my Arca experience is the importance of pouring into the next generation. I look for opportunities to mentor newer security folks every chance I get. I've made this a priority since my days at Arca. It's not like I came up with this on my own -- I've reflected on what I was taught by all the Arca industry giants -- pour into others, as the return is great. As the Internet bubble was in full swing, Arca was acquired not once but twice. The first acquisition didn't stick, as the acquiring company had some issues, and we landed as the new security consulting arm of Exodus Communications. Exodus was the company that everyone used, but most had no idea. Exodus, at its peak, had 44 data centers worldwide, and three out of every four clicks on the Internet went through our data centers. I started as a Senior Security Consultant and migrated into Incident Response. Exodus brought together a group of ex-FBI agents and people like me that had been using computers for decades. We investigated many major breaches and worked on industry-wide security events under the guise of the Cyber Attack Tiger Team or CATT. When the Internet bubble burst, so did Exodus, and I was back on the move. I had a few jobs between Arca and Exodus, all without leaving. **My takeaway from this time was to reinvent yourself often**. I went from consulting to Incident Response and learned a whole new discipline. I leaned into all the Exodus CATT team members could teach me -- learning from trained investigators from the FBI and other Intelligence agencies. Reinvent and never stop learning. Our field is so large we must all continue to learn new things. After Exodus, I had a brief and uneventful stint at a Government Contractor. From there, I landed at Cisco and worked on Common Criteria and FIPS 140 certifications for five years. After leaving certifications and joining an inward-facing product security team, I was challenged to bring threat modeling to the whole engineering organization. I dove deep into threat modeling, grasping how to perform it. I was the Chief Security Advocate at Cisco for five years, and one of the things I did there was work with Erick Lee to define requirements for Cisco’s threat modeling tool (which Erick did all the coding for). Afterward, I worked toward distributing the tool to engineers across the company. We saw success in our efforts as threat modeling became a prominent piece of Cisco’s Secure Development Lifecycle (CSDL). After a few years, I left Cisco to start Security Journey. First, I built a product that teaches developers and product-adjacent people the foundational, intermediate, and advanced facets of application security. Then, I led Security Journey to an exit in 2022. (If you are wondering, in my next chapter as CEO of Kerr Ventures, I'll split my time between startup investing/advising, consulting, and incubating my next idea(s).) I've written all my learnings from Security Journey in a series of yearly posts that you'll find on the [Kerr Secure Blog](https:;/kerrsecure.com). When I ponder all the different job functions and opportunities that I had, I realize that while the technical side of security is important, it's the easier part of what I've accomplished. **The soft skills of leadership are things that I developed by watching excellent leaders lead.** From my managers at Arca to Tom Sweeney at Cisco, I learned how to lead by watching others lead well. I'll never forget my favorite Tom Sweeney quote -- "Judge yourself not by the number of people you manage, but by how many managers you create." This embodied Tom's philosophy -- **pour into people**. Back on the security side, as I think about everything I've seen on my personal security journey, it feels like we've come so far, yet we have so much further. In my time, we've gone from a client-server desktop-focused world to fully networked, containerized, and cloud-native delivery. The technology we rely upon has revolutionized how we deliver IT and applications, yet we still have threats. The threat landscape has changed over time as new attackers enter the scene, new attack scenarios are dreamed up and implemented, and the number of interconnected devices has exponentially grown. At the end of the day, it still comes back to threats. The threats are consistent across the decades, and the need to understand them and mitigate them continues to be a priority. In my career around application security, I've watched the industry go from waterfall to Agile to DevOps. When I ponder the application security impacts, we are doing the same activities with DevOps that we did with waterfall at a more increased pace. Threat modeling is important in all methodologies, just like SAST, DAST, SCA, CVA, and RASP should be incorporated into every application security program today. While some things change, some things stay the same. I often wondered in the early days of my career if we would run out of threats and put ourselves out of jobs by solving all the security challenges. I thought there was a chance in those early days, but as the years went by, I understood that I'd retire from this industry someday, and the threats would still exist. They would look different than when I started, but there will be plenty of room for engineers to continue to tackle the newest threats that impact the human beings of the Internet. We still need more people in our industry. We can argue about how many people we need, but we can all agree that we need more people. I don't see myself moving away from the world of security. I dream of being like my friend Brook Schoenfield when I grow up, continuing to share my knowledge and experience across our industry. Brook calls himself the "Elder Statesman of AppSec." Someday, I hope to be invited to that group. I feel like I still have much more to learn. --- ### The Security Champion Framework - URL: https://kerrsecure.com/2023/01/01/the-security-champion-framework/ - Published: 2023-01-01 - Subject: Developers & Security Culture - Author: Chris Romeo After the release of the [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/), which was a gigantic success, both as a collaborative working group amongst fifteen Threat Modeling experts, and as the seminal work defining the essence of threat modeling, Marc French, Adam Shostack, and I talked about what we could do next to improve the world of application security. We identified a need for a document that helps people new to Security Champions build a program. We created a new working group to create similar work to the TM Manifesto for Security Champions. We waffled between creating a Security Champion Manifesto, a framework, a book, or a series of blog posts. Ultimately, the Champion group lost steam due to circumstances that took various team members away from the project, including me, at the time. From the beginning of the effort, I had envisioned that the output should be a framework and a maturity model for Champion programs. My vision was a document that would capture various maturity levels across the most important pillars of a program. My thoughts crystallized in various talks I delivered in 2022. I started at RSA with a talk entitled "Elite Security Champions Build Strong Security Culture in a DevSecOps World," which a recording can be found on Youtube: [https://youtu.be/9gVM93a1H1I](https://youtu.be/9gVM93a1H1I). I delivered a refined version for the ISC2 Security Congress, where I fleshed out the initial categories of the Security Champion Framework. The framework categories are based on my experience running a large-scale Champion program at Cisco from 2011-2016 and consulting and advising various Champions programs as a consultant from 2017-2022. I've collected feedback from other practitioners and program builders. I want the framework to be larger than my experience and capture the experience of experts from around the globe. Using the words of the framework itself, "The Security Champion framework exists as a measuring stick and a roadmap. As a measuring stick, the framework allows leaders to measure how well their champions program performs. As a roadmap, the leader can use the measurements as input and build a plan to improve their program by applying updates towards a higher framework level." Five high-level areas divide the framework, with one to four sub-areas within each area.
AreaDescription
PlanningPlanning includes the activities needed to scope and build a strategy.
PeoplePeople include recruiting, retaining, capturing commitment, and onboarding new champions.
MarketingMarketing includes the branding of the program and communication plans.
ExecutionExecution includes the program pillars, coaching, education, and globalization efforts.
MeasurementMeasurement includes metrics for demonstrating the value generated by the program.
The Framework is released as CC-4.0-Sharealike. We are accepting PRs as feedback and additions to the framework. Please dive deeply into the framework and put it into use, and let us know of anything we missed: [https://github.com/edgeroute/security-champion-framework](https://github.com/edgeroute/security-champion-framework) --- ### Saying goodbye to Security Journey - URL: https://kerrsecure.com/2022/12/31/saying-goodbye-to-security-journey/ - Published: 2022-12-31 - Subject: The Security Journey Years - Series: The Security Journey Years, part 7 - Author: Chris Romeo Dear Security Journey, As I prepare to depart the company, I’ve had time to reflect on what Security Journey means and why Deb and I built it the way we did. We started in 2016 with me as a traveling security consultant and moved into a product company with eighty customers before the acquisition. We started Security Journey to change how the industry approaches security training. We focused on providing an experience that changes security culture rather than checking a training box. We built something that our customers needed, and we based it on real-world experience. Security Journey was born from all I learned at Cisco about creating an excellent educational experience. It all starts with the content, whether video or hands-on. The content must drive everything you do now and into the future. The content’s quality sets Security Journey apart from the competition. Of course, the platform is essential, as the administrators need features to execute their programs. Still, the content makes Security Journey stand apart, and each learning unit represents a small step toward changing security culture. Our approach has been to create the most excellent technical content and boil topics down to the most critical pieces a developer needs to know. So I am excited to see where the content engine goes in the future. Fight for our Customers; from Customer Success to Sales to Product to Marketing to Engineering, keep the Customer at the center of everything you do. Partner with them, learn from them, and do what’s right for them. In my mind, I’ve completed the task I set out to achieve: build a product that changes security culture. Now I leave the future to you as Security Journey team members. Take this product further than I ever imagined; use your creativity, knowledge, and skills to continue to revolutionize the industry. I have faith in you. I’ll be cheering you on from a distance. As a Board Member, I’m available to do anything I can to help you succeed. So feel free to reach out if there is anything that I can do to help you achieve your mission. Thanks, Chris Romeo Co-Founder of Security Journey --- ### Thirty-one random #AppSec Thoughts - URL: https://kerrsecure.com/2022/11/19/thirty-one-random-appsec-thoughts/ - Published: 2022-11-19 - Subject: AppSec Programs & Practice - Author: Chris Romeo Over October 2022, for NCSAM, I shared thirty-one random AppSec thoughts. For some of these thoughts, I've pointed to other writings I've prepared covering the topics more in-depth. 1. Shift left and shift right = Secure Development Lifecycle. What’s old is new again. - Read more -- [Secure Development Lifecycle: The essential guide to safe software pipelines](https://kerrsecure.com/2022/08/29/secure-development-lifecycle-the-essential-guide-to-safe-software-pipelines/) 2. With all the attention on API security, we often overlook the OWASP API Security Top Ten. - Read more -- [OWASP API Security Top 10: Get your dev team up to speed](https://kerrsecure.com/2022/08/29/owasp-api-security-top-10-get-your-dev-team-up-to-speed/). 3. The OWASP Proactive Controls is the answer to how to fix/avoid the issues of the OWASP Top Ten. - Read more -- [OWASP Proactive Controls: the answer to the OWASP Top Ten](https://kerrsecure.com/2022/11/10/owasp-proactive-controls-the-answer-to-the-owasp-top-ten/) 4. #ThreatModeling is analyzing representations of a system, to uncover the security and privacy challenges that exist. - Read more -- [The best threat modeling representation](https://kerrsecure.com/2022/11/05/the-best-threat-modeling-representation/) 5. Why do we have so many 4-letter acronyms in #AppSec? SAST, DAST, IAST, and RASP, oh my! 6. Security culture is measured by what your developers do with a security problem when nobody is looking. - Read more -- [6 ways to develop a security culture from top to bottom](https://kerrsecure.com/2022/08/29/6-ways-to-develop-a-security-culture-from-top-to-bottom/) 7. Security champions are a force multiplier for your security team. - Read more -- [Information security needs community: 6 ways to build up your teams](https://kerrsecure.com/2022/08/29/information-security-needs-community-6-ways-to-build-up-your-teams/) 8. Imagine a future where all developers are security enlightened. 9. Everyone is a security person — no matter your functional role within the organization, you own a piece of the security solution. 10. Security culture eats strategy for breakfast. 11. People, process, tools, and GOVERNANCE. Governance is the piece that everyone always forgets. 12. Security should never be a gatekeeper — security should open doors, not shut them. - Read more -- [Why developers dislike security—and what you can do about it](https://kerrsecure.com/2022/08/28/why-developers-dislike-security-and-what-you-can-do-about-it/) 13. Regardless of how much effort you put into breaking, security is no better until the builders engage. 14. OWASP is a treasure trove of security resources. - Read more -- [How to do application security on a budget](https://kerrsecure.com/2022/08/28/how-to-do-application-security-on-a-budget/) 15. Break the build for vulnerable open source and third-party, but provide a filtering mechanism to allow builds to progress when there is no known fix. 16. Shift {left, right, outwards} – just start. 17. The Sec in #DevOps is silent. 18. GitHub is a terrible place to store secrets. 19. Teach the developers the underlying principles of the tools, and then watch how the tools magnify #AppSec. 20. Security requires the ability to sell and market. The best security people can explain their idea well, share the value prop, and communicate. 21. Developers take pride in their craft — they want to create more secure code — you must show them the way. 22. Pipelines are the best way to represent a #DevSecOps build pipeline. 23. Developers must understand all the component pieces of the build pipeline. Developers are smart — they’ll provide feedback on those pieces and help tune the tools. 24. Launching a new security tool does not mean we enable every policy — increasing the fidelity of the security tool results in developer buy-in. 25. Security people must learn how to code. The resources on the Internet are vast, and the excuses for why you don’t need to code are few. 26. The DevSecOps Maturity Model (DSOMM) is an assessment tool for your DevSecOps and a builder of roadmaps. 27. As a security professional, drop the no; try “yes, if.” Be a partner and not a roadblock. 28. Threat modeling uncovers design-related issues, and the best threat modeling tool is the human brain. 29. Guard rails are a better strategy than roadblocks. Provide limits, and encourage creativity within the boundaries. 30. At the end of the day, #AppSec is a people-based solution, with support from the process and the tools. 31. We have too many data streams in an #AppSec program; look for tools to correlate and consolidate the streams into developer-usable results. --- ### OWASP Proactive Controls: the answer to the OWASP Top Ten - URL: https://kerrsecure.com/2022/11/10/owasp-proactive-controls-the-answer-to-the-owasp-top-ten/ - Published: 2022-11-10 - Subject: AppSec Programs & Practice - Author: Chris Romeo The [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/) is one of the best-kept secrets of the OWASP universe. Everyone knows the [OWASP Top Ten](https://owasp.org/Top10/) as the top application security risks, updated every few years. The OWASP Proactive Controls is the answer to the OWASP Top Ten. Proactive Controls is a catalog of available security controls that counter one or many of the top ten. For example, Injection is a famous top ten item, having lived within the OWASP Top Ten since its inception. One still prevalent category of Injection is SQL Injection. The counter to SQL injection from the proactive controls is "C3: Secure Database Access" and other controls. C3 prescribes secure queries, configuration, authentication, and communication for database transactions. These techniques work together to prevent data loss due to SQL Injection. Here is a map between the OWASP Top Ten 2021 and the Proactive Controls updated in 2018.
OWASP Top Ten 2021Proactive Controls 2018
A01:2021-Broken Access ControlC7: Enforce Access Controls
A02:2021-Cryptographic FailuresC2: Leverage Security Frameworks and Libraries
C8: Protect Data Everywhere
A03:2021-InjectionC3: Secure Database Access
C4: Encode and Escape Data
C5: Validate All Inputs
A04:2021-Insecure DesignNo mapping
A05:2021-Security MisconfigurationNo mapping
A06:2021-Vulnerable and Outdated ComponentsC2: Leverage Security Frameworks and Libraries
A07:2021-Identification and Authentication FailuresC6: Implement Digital Identity
A08:2021-Software and Data Integrity FailuresC2: Leverage Security Frameworks and Libraries
C4: Encode and Escape Data
C5: Validate All Inputs
A09:2021-Security Logging and Monitoring FailuresC9: Implement Security Logging and Monitoring
C10: Handle all Errors and Exceptions
A10:2021-Server-Side Request ForgeryC5: Validate All Inputs
Let's explore each of the OWASP Top Ten, discussing how the pieces of the Proactive Controls mitigate the defined application security risk. ## A01 Broken Access Control Broken Access Control is when an application does not correctly implement a policy that controls what objects a given subject can access within the application. An object is a resource defined in terms of attributes it possesses, operations it performs or are performed on it, and its relationship with other objects. A subject is an individual, process, or device that causes information to flow among objects or change the system state. The access control or authorization policy mediates what subjects can access which objects. In the worst cases, authorization is forgotten and never implemented. The Proactive Controls offer C7: Enforce Access Controls, which describes Discretionary, Mandatory, Role-based, and Attribute-based access control strategies. The document also provides a solid list of design principles for access control. **Action: Attribute-based access control (ABAC) is the most mature and capable of all the strategies. Use ABAC as your template, and apply the access control design principles.** ## A02 Cryptographic Failures Cryptographic failures are breakdowns in the use of cryptography within an application, stemming from the use of broken or risky crypto algorithms, hard-coded (default) passwords, or insufficient entropy (randomness). A broken or risky crypto algorithm is one that has a coding flaw within the implementation of the algorithm that weakens the resulting encryption. A risky crypto algorithm may be one that was created years ago, and the speed of modern computing has caught up with the algorithm, making it possible to be broken using modern computing power. A hard-coded or default password is a single password, added to the source code, and deployed to wherever the application is executing. With a default password, if attackers learn of the password, they are able to access all running instances of the application. Insufficient entropy is when crypto algorithms do not have enough randomness as input into the algorithm, resulting in an encrypted output that could be weaker than intended. Proactive Controls offer two solutions for cryptographic failures: C2: Leverage Security Frameworks and Libraries and C8: Protect Data Everywhere. C2 prescribes the use of known good security frameworks and libraries. The same holds true for the source of cryptographic algorithms and implementations. Find a reliable, trusted source for your cryptographic functions, and rely upon that implementation to deliver your application's cryptographic needs. C8 calls for data protection everywhere, in transit between your application and users and while resting in a database. **Action: Find a solid, trusted crypto library for your application and encrypt sensitive data in transit and at rest.** ## A03 Injection An injection is when input not validated properly is sent to a command interpreter. The input is interpreted as a command, processed, and performs an action at the attacker's control. The injection-style attacks come in many flavors, from the most popular SQL injection to command, LDAP, and ORM. Proactive Controls has a plethora of options to deal with injection. C3: Secure Database Access was tailor-made to counter SQL injection. C3 includes securing the queries with prepared statements and using object-relational mapping libraries to isolate the raw creation of SQL queries. Secure configuration, authentication, and communication protect the database server and the database's connection parameters. C4: Encode and Escape Data protects any data that is reflected back to the client, and C5: Validate All Inputs ensures that the input that comes inbound is validated using various rules. **Action: Validate all input, and avoid exposing any input directly to an interpreter.** ## A04 Insecure Design An insecure design focuses on the design and architectural flaws. Many future vulnerabilities can be prevented by thinking about and designing for security earlier in the software development life cycle (SDLC). There is no specific mapping from the Proactive Controls for Insecure Design. The Top Ten calls for more threat modeling, secure design patterns, and reference architectures. Threat modeling analyzes a system representation to mitigate security and privacy issues early in the life cycle. Secure design patterns and reference architectures provide a positive, secure pattern that developers can use to build new features. **Action: Threat model everything in sight and use secure design patterns and reference architectures as the foundation for anything new.** ## A05 Security Misconfiguration Security misconfiguration is when an important step to secure an application or system is skipped intentionally or forgotten. Examples of security misconfiguration include missing appropriate security hardening, unnecessary features being enabled or installed, default accounts being enabled and unchanged, error handling bleeding information, disabling security features, or setting application frameworks to insecure settings. There is no specific mapping from the Proactive Controls for Security Misconfiguration. The Top Ten calls for a repeatable hardening procedure as the foundation of how to counter security misconfiguration. C2: Leveraging Security Frameworks and Libraries could result in choosing frameworks with secure default configurations, which would counter various security misconfigurations. **Action: Harden everything within your environment, and look for frameworks with secure defaults.** ## A06 Vulnerable and Outdated Components The world of software is made up of various libraries and frameworks. Developers write only a small amount of custom code, relying upon these open-source components to deliver the necessary functionality. Vulnerable and outdated components are older versions of those libraries and frameworks with known security vulnerabilities. An application could have vulnerable and outdated components due to a lack of updating dependencies. A component, in this case, was added at some point in the past, and the developers do not have a mechanism to check for security problems and update their software components. Sometimes developers unwittingly download parts that come built-in with known security issues. The Proactive Controls doesn't have direct instructions to update dependencies often; there is a close match with C2: Leverage Security Frameworks and Libraries. The critical thing to remember is that when you use frameworks and libraries, you must instill a plan to check for known vulnerabilities and update those dependencies. Dependencies link to other dependencies, which results in an application relying upon thousands of packages with limited visibility to the developer of all those packages. Libraries and frameworks age like milk -- they quickly curdle and need to be replaced with newer versions. **Action: If you use a framework or library, check for known vulns and update often!** ## A07 Identification and Authentication Failures Identification and authentication failures occur when an application cannot correctly resolve the subject attempting to gain access to an information service or properly verify the proof presented as validation of the entity. This issue manifests as a lack of MFA, allowing brute force-style attacks, exposing session identifiers, and allowing weak or default passwords. The Proactive Controls prescribes C6: Implement Digital Identity, which ties into the advanced authentication requirements presented in NIST 800-63b. Guidance is also provided about cookies, tokens, and the use of JWT. **Action: Implement the highest level you can support from NIST 800-63b.** ## A08 Software and Data Integrity Failures Software and data integrity failures include issues that do not protect against integrity failures in software creation and runtime data exchange between entities. One example of a failure involves using untrusted software in a build pipeline to generate a software release. Another example is insecure deserialization, where an application receives an object from another entity and does not properly validate that object, resulting in an attack being loosed upon the application that received the object. Use the Proactive Controls for validation and encoding (C4: Encode and Escape Data and C5: Validate All Inputs) to prevent insecure deserialization. Properly encode output and use JSON and other object-oriented binary styles. To protect the inputs in a build pipeline, rely upon C2: Leverage Security Frameworks and Libraries to ensure that you use the best possible components available, and enact methods to ensure that you have the released version of the software and not something that has been tampered with by an attacker. **Action: Enhance integrity by validating the software you use, and avoid serialization; instead, use JSON as a text format for inter-system data exchange.** ## A09 Security Logging and Monitoring Failures Logging is storing a protected audit trail that allows an operator to reconstruct the actions of any subject or object that performs an action or has an action performed against it. Monitoring is reviewing security events generated by a system to detect if an attack has occurred or is currently occurring. A failure is when either of these actions is not performed correctly. The Proactive Controls provide C9: Implement Security Logging and Monitoring, with direct guidance on tips and tricks for successful logging, avoiding other potential pitfalls that could result in attack conditions in the logging system. C10: Handling all Errors and Exceptions provides additional context for extending applications to reflect error conditions. The application has visibility into your logging and monitoring constructs. **Action: Just log and monitor; it may be near the bottom of the list, but it is the only way to know what steps have been performed against your system.** ## A10 Server Side Request Forgery (SSRF) A Server Side Request Forgery (SSRF) is when an application is used as a proxy to access local or internal resources, bypassing the security controls that protect against external access. While the Proactive Controls do not specifically address SSRF, C5: Validate All Inputs includes the validation of URL parameters, which are the root of most SSRF vulnerabilities. **Action: Validate any URLs allowed as input, and filter out any SSRF conditions.** ## Conclusion While the current OWASP Proactive Controls do not match up perfectly with the OWASP Top Ten for 2021, they do a fair job of advising on controls to add to your applications to mitigate the dangers the Top Ten describes. Ironically, the only Proactive Control that does not line up with one of the OWASP Top Ten 2021 items is C1: Define Security Requirements. C1 describes security requirements, points to the OWASP Application Security Verification Standard (ASVS) as a source, and describes a path for implementing security requirements. Proper security requirements can assist in limiting the blast radius of the OWASP Top Ten. Shifting left is a real thing, marketing term or not, and considering requirements early in the process of building something new lessens the impact of the OWASP Top Ten. ## References - [OWASP Top Ten](https://owasp.org/Top10/) - [OWASP Proactive Controls](https://owasp.org/www-project-proactive-controls/) - [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/) - [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/) - [OWASP MASVS](https://github.com/OWASP/owasp-masvs) --- ### The best threat modeling representation - URL: https://kerrsecure.com/2022/11/05/the-best-threat-modeling-representation/ - Published: 2022-11-05 - Subject: Threat Modeling - Author: Chris Romeo The [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/) defines threat modeling: as "analyzing representations of a system to highlight concerns about security and privacy characteristics."A representation is the foundation of threat modeling. It is the item that threat modelers use to capture the essence of the thing they are modeling. Without a solid representation, it is challenging to draw robust security or privacy conclusions. A representation takes many different forms: - **Data flow diagram** -- a process diagram that simplifies in-depth flowcharting using a limited set of elements including process, data flow, data store, external entity, and trust boundary. - **Attack tree** \-- an attack tree is a conceptual diagram showing how an asset or target might be attacked. - **Swim lane diagram** -- visually distinguishes job sharing and responsibilities for sub-processes of a business process. - **Pseudo-code** -- a plain language description of the steps that code will eventually perform. - **Napkin** -- the simplest form of representation could be a napkin scribbled upon a napkin over a lovely lunch meeting. The takeaway is that while a representation can take many different forms, all representations have the same function. A representation exists to help the threat modeling team unlock the best possible set of threats and mitigations for whatever the representation represents. Many threat modelers participated in a poll on LinkedIn, answering the question, "when threat modeling, what do you use to create a representation?" As you see, data flow diagrams are the most used representation. Avi Douglen and Izar Tarandach, well-known leaders in the world of threat modeling, espouse data flow diagrams' use. Each of them also adds other representations to their explanations. Swim lanes and Wardley maps for Avi and Python code ([PyTM](https://owasp.org/www-project-pytm/)) for Izar. > DFDs most often for new models, lately been using swimlanes more (especially if devs already have them). I am also trying out / experimenting with a focused Wardley map as well, not really confident in this yet but it feels really powerful. > > [Avi Douglen](https://www.linkedin.com/in/avidouglen/) > Whichever works best for the owners of the system to better express it via the model. If it is me, then probably DFDs. Or Python code! > > [Izar Tarandach](https://www.linkedin.com/in/izartarandach/) Steve Springett summarizes the benefits of multiple representations in his descriptions of how he uses DFDs and Attack Trees to best understand and discover the threats within the things he models. > Why just one? DFDs and attack trees are commonly used in my threat models. In my experience, the DFD can inform the Attack Tree since the DFD will have all the assets and processes that can be attacked. The Attack Tree can then identify things in the DFD that were previously marked as out of scope and we can reevaluate if that truly is the case. But I always start out with a DFD. > > [Steve Springett](https://www.linkedin.com/in/stevespringett/) The takeaway here is that with threat modeling, there is no best representation. Use the representation that makes the most sense, and look for opportunities to add additional representations to your process. Expand your mind and your representations to make even better threat models. Don't be afraid to use a new representation. The best threat modeling exercises a creative mind, as part art and part science. --- ### Threat modeling and a lack of tools - URL: https://kerrsecure.com/2022/10/29/threat-modeling-and-a-lack-of-tools/ - Published: 2022-10-29 - Subject: Threat Modeling - Author: Chris Romeo I've been threat modeling for quite some time. I could argue that I started threat modeling at a high level in 1997 when I started my first job working for one of the first security consulting firms, Arca Systems. Threat modeling was a crucial part of everything we did, but we didn't call it threat modeling or a separate process. It was how we were taught to think. I taught myself the formal threat modeling processes I eventually rolled out at a large tech company. I started with [STRIDE](https://en.wikipedia.org/wiki/STRIDE_\(security\)) and used that as the foundation for how I taught people the threat modeling process. We took that process and turned it into a tool that helped walk engineers through the process of threat modeling. The core principle of the tool was that it should allow an engineer to be the expert in the thing they were building, but not in security. The tool asked the engineer to create a representation, tag that model with attributes, and then consider the threats/develop mitigations. The tool led the engineers through the process. The tool's goal was to put itself out of business over time. The tool was not designed to always be how threat models were performed. The hope was that engineers would learn the process without needing the tool to facilitate threat modeling. Watching this tool be utilized over time, I thought that tools could enhance any threat modeling program. I still hold true to what we wrote in the [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/), "People and collaboration over processes, methodologies, and tools." Humans must learn how to do threat modeling manually before adopting a technological solution. This is the same circumstance as when we code up a solution to a manual problem. If we do not find a manual solution to the challenge, we could end up coding something that misses the mark. When I asked [the question about tooling usage within the world of threat modeling on LinkedIn](https://www.linkedin.com/posts/securityjourney_appsec-threatmodeling-activity-6978395490686025728-edtj?utm_source=share&utm_medium=member_desktop), I was surprised to learn that most threat modelers are not using any tools. They are using a manual process. This leads me to ask the question, "why?" Is the lack of tool usage a statement about the current maturity of threat modeling in our industry or a comment about a deficiency in the available tools? We have multiple options in the commercial space for tooling, as well as [PyTM](https://owasp.org/www-project-pytm/) and [Threat Dragon](https://owasp.org/www-project-threat-dragon/) from the open-source community. In my experience, it's a combination of both. --- ### The Hybrid Approach to Threat Modeling - URL: https://kerrsecure.com/2022/09/24/the-hybrid-approach-to-threat-modeling/ - Published: 2022-09-24 - Subject: Threat Modeling - Author: Chris Romeo In the pursuit of studying the AppSec person and program in the wild, today's research unpacks the voluntary mandatory debate on threat modeling. Different organizations take different approaches to implementing threat modeling. This is a crucial decision in the life of the AppSec program. The existing engineering and organizational culture have a definite impact on the choice. It is best not to cross the culture with this decision, as that will likely spell defeat for your new undertaking from the beginning. A LinkedIn poll suggests that most respondents approach threat modeling as voluntary but encouraged. _LI Post: https://www.linkedin.com/feed/update/urn:li:activity:6975812523346341888/_ ## The Mandatory Approach Some make threat modeling a mandatory gate and prevent developers from moving a new feature into production if threat modeling is not performed. The status of the threat model is monitored in some way, and if the model has not been uploaded or attached to a ticket, the feature cannot progress through the pipeline. The mandatory approach requires a clear and concise process. As you are forcing teams to perform threat modeling, they will push back heavily if you do not clearly define what it is they must complete. Strengths of mandatory - Whatever you decree is unilaterally applied to all features. - Because everything is being threat modeled, you must expand the creation of the models to developers and the product adjacent. Weaknesses of mandatory - If the team is forced to perform a threat model, they may consider it a compliance artifact and put little effort into it. - The volume of threat models makes governance and review more difficult. ## The Voluntary Approach The other side of the coin is voluntary, where threat modeling is encouraged but does not act as a blocker for a new feature. With voluntary, developers and product adjacent may represent your security champions, with an existing passion and drive for security. Strengths of voluntary - Those that threat model have a desire to threat model. - Models will be of higher quality because voluntary effort is applied. Weaknesses of voluntary - Threat models may not be completed for crucial features. - Security vulnerabilities resulting from design issues could slip into production with no consideration. ## Not doing threat modeling at all. Eight percent of respondents from the survey admitted to not doing any threat modeling. Yet, threat modeling is valuable and returns much more value than it requires. Gaining a culture where developers and product adjacent understand and think about security is priceless. Strengths - Saving resources and limiting disagreements about workload between security and engineering. Weaknesses - Missing out on design-related issues can translate into vulnerabilities in production. - Design-related issues could be at the subsystem level (think authentication or authorization), resulting in total system/application compromise. ## The Hybrid Approach The Hybrid Approach was uncovered and shared by [Julie Davila, CTO, Federal at Sophos](https://www.linkedin.com/in/thisjulie/), on the poll. She described the Sophos threat modeling approach as initially mandatory but only a gate if the new code or integration warrants it. Sophos focuses on empowering engineering teams via security champions to do much triaging and "0 to 80" work for scale. The AppSec team is generally involved with every "first" threat model, and then teams are expected to update this autonomously with the ability to phone for help if needed. The engineering leaders endorse the shared responsibility model and are not purely bottoms-up. No matter what, threat modeling with _every_ code or infrastructure change isn't good or ideal, according to Julie. The reasons to update, broadly speaking, include: - New data flow (having a solid data flow diagram is essential) - New infrastructure (e.g., an app suddenly starts using AWS SNS) - Changes to the type of data going through a system (e.g., a new feature introduces customer PII data) - Changes to encryption - Changes to prior assumptions surrounding a security framework, centralized logging, etc ## Conclusion After considering the options on the poll, the best path forward for an organization is the hybrid approach. Hybrid defines the best of both, allowing the necessary threat modeling control for new features, but also does not push the product teams into threat modeling as busy work. Therefore, hybrid threat modeling is the best path forward for your application security program. --- ### AppSec, We Have a Problem: Not Everyone Knows How to Code - URL: https://kerrsecure.com/2022/09/06/appsec-we-have-a-problem-not-everyone-knows-how-to-code/ - Published: 2022-09-06 - Subject: Developers & Security Culture - Author: Chris Romeo Application and software security professionals have a single focus job description: "help developers write more secure code to limit vulnerabilities." Therefore, everything an AppSec team does should focus back on this single core statement. AppSec teams deploy security tools into build pipelines to discover coding flaws and potential vulnerabilities so that developers can fix those issues before production. AppSec teams teach developers about security, including facets of secure coding principles for the developer's specific tech stack. AppSec teams lead and facilitate threat modeling sessions to identify business logic issues that could hamper security if those issues are allowed to reach production. **All AppSec and Software Security is focused on helping developers write more secure code to limit vulnerabilities.** Can you exist without fundamental knowledge of a single coding language as an application and software security professional? As background, consider "[Why cybersecurity pros need to learn how to code](https://kerrsecure.com/2022/08/28/why-cybersecurity-pros-need-to-learn-how-to-code/)." This post argues how coding knowledge benefits various roles within cybersecurity: AppSec Lead, SOC Analyst / Threat Hunter, Auditor, Pen Tester, and CISO. Finally, the post concludes that there is a benefit for everyone in cybersecurity learning how to code, listing out the coding value proposition for each role. Out of a desire to learn more about the application security community, a LinkedIn poll was created to ask a question of AppSec people, "how many development (coding) languages are you fluent in?" and the answers surprised me a bit. ## No language fluency At first blush, the thought of application security professionals having no knowledge of at least one object-oriented language is astounding. But the picture begins to change if we consider how people make their way into cybersecurity. Not every person makes their way to cybersecurity through a Computer Science background. A student cannot complete a CS degree without learning a few object-oriented programming languages. What if you make your way to cybersecurity through a system administration background? You can administrate many systems and networks without coding. You may learn scripting to make your job easier, but is it true object-oriented coding? Entering cybersecurity through a different door is not a lifelong excuse for not learning how to code. On the contrary, the value and influence of learning a coding language are priceless when working with developers. Imagine a situation where you drop off your car for service, and the mechanic explains that she has a teacher working with her for the day who will instruct her on your repair because of its complexity. The teacher happens to be grabbing a cup of coffee in the waiting room, and you ask how many cars they have mastered this repair on? If the teacher tells you to zero, you will have severe doubts about the safety of your vehicle when you leave that service appointment. Samet thing applies for coding -- you must have domain-level experience in the subject you are asking for influence within. If you find yourself in this boat, know there are inexpensive opportunities to learn that first coding language. From online coding sites to a formal school to pairing with an existing developer, you'll find that if you desire, you'll have the opportunity to learn. ## 1-2 language fluency The largest category of findings was those AppSec professionals fluent in one to two languages. This is encouraging because fluency in a single language prepares you to extend to multiple languages. While each language has its own nuances and details to learn and understand, having a fundamental knowledge of one object-oriented language allows you to apply that knowledge to many other languages. Reading code and advising on design are the two primary efforts that an application security professional must undertake. In addition, knowledge of that single language prepares you to read code in other languages and ask questions of your developer friends. These questions are based on knowledge and not ignorance. > I think software architecture and cross-boundary knowledge is more important than one language, per se. What tends to happen when you cross architectural boundaries you run into multiple languages. Concepts are the same across languages, only different syntax. Solid programming concepts are more important than one language I would argue. Pattern recognition over being an expert in one language is more important. > > [Tony Vargas](https://www.linkedin.com/in/tvargascsslpcisspsecurity/) ## 3-5+ language fluency This 3-5+ group is just showing off. Just kidding. It is excellent that we have application security professionals who have embraced the skills their development populations utilize. People with this much subject matter expertise make a difference when working with their developers. Those developers cannot look at these folks and say, "you don't understand what I do." Language fluency does not mean the ability to code without using any references or resources. Using Google and other sites to help remember the syntax of a new language is not a weakness; it's a superpower. Developers use resources all the time to solve a specific problem. AppSec professionals can use the same resources for success. Beyond language fluency, the best application security professionals understand the entire development lifecycle beyond language fluency. From source code control systems, issue trackers, and build pipelines, the best of the best understand all that developers have to deal with and can advise and roll up their sleeves alongside the development teams. ## Conclusion If you're an application security professional that doesn't know how to code yet, do not feel shame after reading this article -- be excited to expand your mind as a lifelong learner and pick up that first coding language. Python is a great place to start, given the depth and breadth of available information, tutorials, and videos online. Take this article as a charge to learn what your developers know so that you can achieve the core application security mission -- "help developers write more secure code to limit vulnerabilities." --- ### OWASP Top 10 2021: 7 action items for app sec teams - URL: https://kerrsecure.com/2022/08/29/owasp-top-10-2021-7-action-items-for-app-sec-teams/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo In the world of application security, the OWASP Top 10 2021 is the most famous—or infamous—of documents. Loved by most and hated by a few, this foundational document is the first thing people on most application security programs try to assimilate and conquer. With the [OWASP Top 10 2021](https://owasp.org/Top10/), application security teams certainly have work to do. But if you embrace it, your app sec team will get better. Here are seven things practitioners can take action on from the new OWASP Top 10. ### 1\. Item No. 10 is just as crucial as item No. 1 When the new Top 10 was released, some looked at the list and questioned the order. Is A01, "Broken Access Control," more of an issue than A10, "Server-Side Request Forgery" (SSRF)? The simple answer is not to get hung up on the order of things on the list. If you have an SSRF in your Internet-facing web application, that issue trumps everything else you’re facing. _**Takeaway: The order of issues on the top 10 is not the important thing; deal with the highest-risk issues that stand in front of you.**_ ### 2\. Define your mitigation guidance specific to the needs and wants of your organization Your primary focus must be on mitigating defined issues. Your goal is to eliminate whole classes of flaws over a period. The OWASP Top 10 has some guidance on mitigation/prevention, but it’s not actionable. As a random example, from "Broken Access Control": “Rate limit API and controller access to minimize the harm from automated attack tooling.” Rate limiting is a good goal but a tough user story/requirement to hand to a developer. _**Takeaway: Mitigate issues using organizationally specific prevention and mitigation steps.**_ ### 3\. Think of A04, 'Insecure Design,' as floating above all the other items Insecure design is the root of the other nine items on the list. A cryptographic failure started as an answer to a user story where someone said, “This crypto key size is good enough.” If a proper threat model had been performed for the new crypto feature before coding, the issue more than likely would have been discovered. Among the available tools and technologies that could eliminate vulnerabilities, threat modeling is the only discipline that could impact every item on the Top 10 list. _**Takeaway: Implement threat modeling as a solution for all 10 items on the list.**_ ### 4\. Incorporate other OWASP projects to solidify your program’s foundation Since the list's inception, people have called the Top 10 a standard, and while the OWASP team has pushed back against that for years, it has finally accepted it and added a section called “How to use the OWASP Top 10 as a standard.” This title is a bit tongue-in-cheek, though, since the section states once again the list is an awareness document and then points to the other projects that help you form a solid program foundation. The Application Security Verification Standard (ASVS) is pointed to as the verifiable standard and is the recommended choice for the depth you need to run a program. The Proactive Controls, which tries to answer the question of how to fix the Top 10 issues, is now under revision to match up with the new Top 10. _**Takeaway: The Top 10 is flashy, but it’s a mile wide and an inch deep. ASVS, together with Proactive Controls and the Top 10, is a mile wide and a mile deep.**_ ### 5\. Teach the CWEs Common Weakness Enumerations have been part of the Top 10 since at least 2017. This year the CWEs are more front and center, and a wider distribution of CWEs was considered in the team’s analysis. As you present the new Top 10 to your developers, take them back to the foundational CWE nature of each issue. _**Takeaway: Ensure that developers have perspective on how CWEs work and how they can use them to understand and mitigate issues.**_ ### 6\. Follow the resources The resource lists found within the Top 10 are a hidden treasure of application security goodness. As an example, "Broken Access Control" offers pointers to Proactive Controls, ASVS, OWASP Testing Guide, and OWASP Cheat Sheets. The mappings align with specific areas in those other documents that assist the program in dealing with the issue. Following the resources can show you how to transform your products and applications on an issue-by-issue basis. _**Takeaway: Go beyond the surface of each item on the list and take your teams deep into understanding, testing, and mitigating the issues.**_ ### 7\. SSRF is a hidden danger that almost nobody understands Remember when cross-site request forgery (CSRF) first arrived on the scene? It was a challenging class of issues to explain because it had multiple moving parts. SSRF is now in the same boat. Ask 10 application security people what SSRF is and how to mitigate it and you’ll get a widely varied selection of answers and levels of understanding. _**Takeaway: Given the deadly nature of a single SSRF issue, it's a good idea to invest in increasing understanding and mitigations.**_ ### Unlock the potential While the OWASP Top 10 is seen as a “standard,” it requires more effort by you, the practitioner, to unlock its true potential. Lists of preventions and a few examples are great, but they are not a holistic approach to application security. [Use the OWASP Top 10](https://owasp.org/Top10/) for what it was initially designed for: awareness. Use it to teach your team the top issues they must understand. And look to all the other OWASP resources to fill in the gaps. --- ### 6 ways to develop a security culture from top to bottom - URL: https://kerrsecure.com/2022/08/29/6-ways-to-develop-a-security-culture-from-top-to-bottom/ - Published: 2022-08-29 - Subject: Developers & Security Culture - Author: Chris Romeo > “We don’t need security.” With our modern dependence on technology and security, nobody would dare to make this statement. Everyone knows how crucial security is and how it must be embedded into everything an organization does. A simple glance at the news provides details on the data breach of the day tied to an application security vulnerability. Take a stroll to the Information Security department and you'll hear about the latest blunder an employee made that resulted in lost data. Security is widespread and mainstream, but _security culture_ has not kept pace with the threat landscape. Tim Ferriss shared his definition of culture as “what happens when people are left to their own devices.” This applies to security culture if we inject “with security” into that definition: Security culture is what happens with security when people are left to their own devices. Do they make the right choices when faced with whether to click on a link? Do they know the steps that must be performed to ensure that a new product or offering is secure prior to ship? ## Building a healthy security culture  An organization’s security culture requires care and feeding. It is not something that grows in a positive way organically. You must invest in security culture. A sustainable security culture is bigger than just a single event. When a security culture is sustainable, it transforms security from a one-time event into a lifecycle that generates security returns forever. Sustainable security culture has four defining features. First, it is deliberate and disruptive. The primary goal of a security culture is to foster change and better security, so it must be disruptive to the organization and deliberate with a set of actions to foster the change. Second, it is engaging and fun. People want to participate in a security culture that is enjoyable and a challenge. Third, it is rewarding. For people to invest their time and effort, they need to understand what they will get in return. Fourth, it provides a return on investment. The reason anyone does security is to improve an offering and lower vulnerabilities; we must return a multiple of the effort invested. A strong security culture not only interacts with the day-to-day procedures but also defines how security influences the things that your organization provides to others. Those offerings may be products, services, or solutions, but they must have security applied to all parts and pieces. A sustainable security culture is persistent. It is not a once-a-year event but embedded in everything you do. Why does an organization need a security culture? The primary answer is something that deep down we all know. In any system, humans are always the weakest leak. Security culture is primarily for humans, not for computers. The computers do exactly what we tell them to do. The challenge is with the humans, who click on things they receive in email and believe what anyone tells them. Humans need a framework to understand what the right thing is for security. In general, humans within your organization want to do the right thing—they just need to be taught. Luckily, wherever an organization sits on the security culture spectrum, there are things that can be done to make the culture better. ### 1\. Instill the concept that **security belongs to everyone** Many organizations have the opinion that the security department is responsible for security. Sustainable security culture requires that everyone in the organization is all in. Everyone must feel like a security person. This is a security culture for everyone. Security belongs to everyone, from the executive staff to the lobby ambassadors. Everyone owns a piece of the company’s security solution and security culture. Samantha Davison, security program manager at Uber, says, “At Uber, we are trying to change our employees' security stories. By creating programs catered to region, department, and role, our people understand that security is part of their story and our culture.” This is an example of a company that truly believes that security belongs to everyone and bakes security into everything they do. You can achieve this “all in” mentality by incorporating security at the highest levels into your vision and mission. People look to these things to understand what they should focus on. Update your vision or organizational objective to clearly articulate that security is non-negotiable. Speak about the importance of security from the highest levels. This does not mean just the people who have security in their title (CISO, CSO), but also from other C-level execs all the way down to individual managers. ### 2\. Focus on **awareness and beyond** Security awareness is the process of teaching your entire team basic lessons about security. You must level set each person’s ability to judge threats before asking them to understand the depth of the threats. Security awareness has gotten a bad rap because of the mechanisms used to deliver it. Posters and in-person reviews can be boring, but they do not have to be. Add some creativity to your awareness efforts. On top of general awareness is a need for application security knowledge. Application security awareness is for the developers and testers within the organization. In your organization, they may sit within IT, or they may be the engineering function. AppSec awareness is teaching the more advanced lessons that staff need to know to build secure products and services. Awareness is an ongoing activity, so never pass up a good crisis. Bad things are going to happen to your organization, and many times they will be tied directly to a security problem. Grow your security culture with these teachable moments. Do not try to hide them under the rug, but instead use them as an example of how the team can get better. Accountability before awareness is crazy. People want to do the right thing, so show them through an awareness program and then hold them accountable for the decisions they make after gaining the knowledge. ### **3\. If you do not have a secure development lifecycle, get one now** A secure development lifecycle (SDL) is foundational to sustainable security culture. An SDL is the process and activities that your organization agrees to perform for each software or system release. It includes things like security requirements, threat modeling, and security testing activities. SDL answers the how for your security culture. It is sustainable security culture in action. Customers across industries are starting to demand the crazy idea that organizations have an SDL and follow it. If you do not have an SDL at this juncture, Microsoft has released most of the details about its SDL free of charge. The lineage of many industry SDL programs traces back to the Microsoft program. A reasonable place for the SDL to live is within a product security office. If you do not have a product security office, think seriously about investing in one. This office sits within engineering and provides central resources to deploy the pieces of your security culture. While we do not want the entire organization to farm off security to the product security office, think of this office as a consultancy to teach engineering about the depths of security. ### **4\. Reward and recognize** those people that do the right thing for security Look for opportunities to celebrate success. When someone goes through the mandatory security awareness program and completes it successfully, give them a high-five or something more substantial. A simple cash reward of $100 is a huge motivator for people and will cause them to remember the security lesson that provided the money. They also will be quick to tell five co-workers they received cash for learning, and those five will jump into the training quickly. If you are shuddering at the idea of giving away $100 per employee, stop being so cheap and count the cost. The return on investment on preventing just a single data breach greatly outweighs the $100 spent. The other side of reward is security advancement. Provide opportunities for team members to grow into dedicated security roles through advancement. Make security a career choice within your organization. Put your money where your mouth is. If you say security is important, prove it by providing growth potential for those with a passion for security. A final step is to provide an opportunity to earn an advanced degree in security. Many universities now offer a [master's degree in cybersecurity](https://www.csoonline.com/article/552143/so-you-want-a-masters-degree-in-cybersecurity.html). If you can’t find one nearby, create your own. In my previous job, I worked with a large university in California to tailor a degree program that supported the company's security culture. Once again, put your money where your mouth is and sponsor the first group of students. It sends a positive message to the entire organization. ### **5\. Build a security community** The security community is the backbone of sustainable security culture. The community provides connections between people across the organization. The security community assists in bringing everyone together against the common problem and eliminates an "us versus them" mentality. The security community is achieved by understanding the different security interest levels within the organization: advocates, the security-aware, and sponsors. Security advocates are those people with a down-home passion for making things secure. These are the leaders within your community. The security aware are not as passionate but realize they need to contribute to making security better. The sponsors are those from management who help to shape the security direction. Gather all of these folks together into a special interest group focused on security. The security community can manifest as one-on-one mentoring and weekly or monthly meetings to discuss the latest security issues. It can even become a yearly conference, where the best and brightest from the organization have a chance to share their knowledge and skills on a big stage. ### **6\. Make security fun and engaging** Last, but certainly not least, is fun. For far too long people have associated security with boring training or someone saying no all the time. To cement a sustainable security culture, build fun and engagement into all the process parts. If you have specific security training, ensure that it is not a boring voice-over PowerPoint presentation. If you engage your community through events, do not be afraid to laugh and goof around some. In my previous role, at each monthly security community event, we started the meeting off with a game of security trivia with a different security category each month. We did hackers in the movies one month and security news in another. This is just an example of how to bring fun and engagement into the process. Uber's Davison offers: > “Security can be so much more than PowerPoints and videos. Pick a fun theme and parody it—we did Game of Thrones. Give gamification a try. Throw a phishing writing workshop and have your employees write a phishing email for the company. The options are endless when you start to think outside the box.” ## What kind of security culture do you have? Of course, every organization has a security culture. If they say they don't, they are either lying or afraid to admit they have a bad security culture. The good news is that any security culture can positively change how the organization approaches security. But culture change takes time, so don't expect your members of your organization to overnight become pen-testing Ninjas that write secure code while they sleep. With the right process and attitude, you’ll get there. --- ### Secure Development Lifecycle: The essential guide to safe software pipelines - URL: https://kerrsecure.com/2022/08/29/secure-development-lifecycle-the-essential-guide-to-safe-software-pipelines/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo Customers demand secure products out of the box, so security should be a top priority that should be top of mind for everyone. But without a standard approach to security, it is almost impossible to deliver on the customers' expectations. That's where the Secure Development Lifecycle (SDL) comes in. SDL is a process. If you look at the many SDLs that exist across industries, you'll find that most include the same basic security phases and activities. They may have different names for the pieces, but everyone follows roughly the same process. Here's an essential guide to placing security front and center. ### Defining the Secure Development Lifecycle In its simplest form, the SDL is a process that standardizes security best practices across a range of products and/or applications. It captures industry-standard security activities, packaging them so they may be easily implemented. The software development lifecycle consists of several phases, which I will explain in more detail below. The SDL was unleashed from within the walls of Microsoft, as a response to the famous [Bill Gates memo](https://www.wired.com/2002/01/bill-gates-trustworthy-computing/) of January 2002. In it, Gates laid out the requirement to build security into Microsoft's products. He admitted that due to various virus and malware outbreaks, Microsoft had to embed security if it was to be taken seriously in the marketplace. This resulted in the Microsoft Trustworthy Computing endeavor, out of which the idea of SDL was born. Microsoft made the SDL [mandatory in 2004](https://www.microsoft.com/en-us/SDL/resources/evolution.aspx), and a cottage industry was unleashed. Many other companies, including Cisco, Adobe, and Aetna, have since adopted Microsoft's SDL processes or created their own. And Microsoft has been gracious over the years in sharing its SDL successes with other companies and releasing many of its materials and tools as open source. ### The problems the SDL solves The lack of a standard approach to securing products causes problems. For one thing, vulnerabilities run rampant in shipped products. The triage and response needed to deal with this are major resource sinks. As a result, developers spend too much time fixing code they wrote in the past and not enough focus on the future. The second problem is that developers tend to repeat the same security mistakes, each time expecting a different response (which is the definition of insanity). The third issue is that problems are found at release or after deployment, beyond the reasonable time when the problems could be mitigated in an inexpensive manner. Finally, without a security standard customers have no assurance that a given product is secure. A single product considered for purchase may be one of the good ones, or it might be terrible from a security perspective. Without an SDL, there is no product security parity across the company. And without a standard process, some product teams ignore security altogether. ### People, processes, and technology The SDL is a process with different phases that contain security activities that sit inside of the classic people-process-technology triangle. The SDL forms the process portion. It includes both the central security team that governs the process and updates it and the product or development teams that perform security activities. The technology portion consists of tools that assist in finding vulnerabilities in source code or discovering vulnerabilities in a running instance of the product or application. The SDL is methodology-neutral. Security activities fit within any product development methodology, whether waterfall, agile or DevOps. Methodology differences show up in the cadence of security activities. The SDL was developed during the time of waterfall, so it is usually portrayed as a linear process that begins with requirements and ends with the release. When the SDL is extended to agile, some security activities get integrated into the normal sprint schedule, while others are pursued out-of-band. With DevOps, activities are embedded into the build pipeline using automation, while additional activities happen outside the pipeline. An SDL is divided into phases that tie closely into the waterfall approach. The standard approach to SDL includes requirements, design, implementation, test, and release/response. ### The requirements phase In the requirements phase, best practices for security are integrated into a product. These practices may come from industry standards or be based on responses to problems that have occurred in the past. Requirements exist to define the functional security requirements implemented in the product and include all the activities of the SDL. They are used as an enforcement point to ensure that all pieces are properly considered. Requirements may take the classic form, stating that the product or application must, may, or should, do something. One example might be that the product must enforce a minimum password length of eight characters. In the agile world, requirements are expressed as user stories. These stories contain the same information as do the requirements, but security functionality is written from the user's perspective. ### The design phase The design phase of the SDL consists of activities that occur (hopefully) prior to writing code. Secure design is about quantifying an architecture (for a single feature or the entire product) and then searching for problems. The secure design could occur in a formal document or on a napkin. With many systems, the plane is in the air as the wings are being designed, but the SDL can survive even this craziness. The key is to use threat modeling. Threat modeling is the process of thinking through how a feature or system will be attacked, and then mitigating those future attacks in the design before writing the code. Threat modeling is akin to perceiving crimes prior to their occurrence, as in the 2002 movie [_Minority Report_](http://www.imdb.com/title/tt0181689/). A solid threat model understands a feature's or product's attack surface, then defines the most likely attacks that will occur across those interfaces. A threat model is only as good as the mitigations it contains to fix the problems. But it is crucial to identify security issues early in the process. ### Implementation or coding The next phase is the implementation or writing of secure code. The SDL contains a few things programmers must do to ensure that their code has the best chance of being secure. The process involves a mixture of standards and automated tools. On the standards front, a solid SDL defines a secure coding guide (such as those published by SEI CERT for [C](https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard), [C++](https://wiki.sei.cmu.edu/confluence/pages/viewpage.action?pageId=88046682), and [Java](https://www.securecoding.cert.org/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+Java)), that defines what is expected and provides guidance for when developers hit a specific issue and need insight. Implementation tools include static application security testing (SAST) and dynamic application security testing (DAST) software. SAST is like a spell-checker for code, identifying potential vulnerabilities in the source code. SAST runs against a nightly build or may be integrated into your IDE. It may find and open new bugs in the bug management system nightly or prompt the developer to pause while coding to fix a problem in real-time. DAST checks the application's runtime instantiation. It spiders through an application to find all possible interfaces and then attempts to exploit common vulnerabilities in the application. These tools are primarily used on web interfaces. ### The test phase Formal test activities include security functional test plans, vulnerability scanning, and penetration testing. Vulnerability scanning uses industry-standard tools to determine if any system-level vulnerabilities exist with the application or product. Penetration testing involves testers attempting to work around the security protections in a given application and exploit them. Pen testing stretches the product and exposes it to testing scenarios that automated tools cannot replicate. Pen testing is resource-intensive, so it's usually not performed for every release. ### The final phase: Release/response Release occurs when all the security activities are confirmed against the final build and the software is sent to customers (or made available for download). The response is the interface for external customers and security researchers to report security problems in products. Part of the response should include a product security-incident response team that focuses on triaging and communicating product vulnerabilities, both individual bugs and those that will require industry-wide collaboration (e.g., Heartbleed, Bash bug, etc.). Other security activities are also crucial for the success of an SDL. These include security champions, bug bounties, and education and training. ### Think differently, think secure The Secure Development Lifecycle is a different way to build products; it places security front and center during the product or application development process. From requirements to design, coding to testing, the SDL strives to build security into a product or application at every step in the development process. A modern application company cannot survive without getting serious about security, and the way to get serious is to integrate an SDL into your everyday work. --- ### Why OWASP's Threat Dragon will change the game on threat modeling - URL: https://kerrsecure.com/2022/08/29/why-owasps-threat-dragon-will-change-the-game-on-threat-modeling/ - Published: 2022-08-29 - Subject: Threat Modeling - Author: Chris Romeo Threat modeling has always been a dream of mine. Not that I sit around and dream of threat modeling all day, but I dream of embedding a process of security threat modeling within an entire development organization. Threat modeling, the process of discovering potential security vulnerabilities in a design and eliminating those vulnerabilities before writing any code, fits best during the stage of planning and designing a new feature. When threat modeling is firing on all cylinders, an organization is creating more secure software. What if I told you that you already know how to threat model and that you threat-model every day? Think about when you left the house this morning. You closed the door behind you and you began to threat-model the area around you. You heard cars rushing by on the street, exceeding the speed limit. Threat. You heard a dog barking from the direction where you needed to walk. Threat. The sun was beating down on you. Threat. You threat-model all the time as you consider how these different events could damage your person. Threat modeling technology is just applying these same principles to software. ### Threat modeling is a state of mind I’ve found in my 20-plus-year career in security that threat modeling is more than just a tool; it’s a state of mind. Threat modeling is most impactful when it moves from a development process to a developer's state of mind. In the beginning, developers use the process to assist in understanding the steps and repeating the results. As developers become more proficient with threat modeling, the security light bulb goes on over their heads, and their thinking changes. They choose more secure design options without thinking about it. Tooling is important because it lays the foundation of how to perform the threat modeling process and makes it available to a large group of people simultaneously. The challenge with teaching an entire organization to threat model is that there were no decent, simple tools that simplified the process and were usable, until now. Threat modeling is not a new concept. Microsoft pioneered this idea within its SDL years ago, including the development of [the STRIDE methodology](https://en.wikipedia.org/wiki/STRIDE_\(security\)), which drives threat modeling. It even created [the first tool on the market](https://www.microsoft.com/en-us/download/details.aspx?id=49168), and it has updated it a few times over the years. It’s not a bad tool, but it only runs on Windows and focuses its use cases on Windows services and Azure cloud solutions. This is a deal breaker for most of companies that want to adopt an enterprise approach to threat modeling. With all the diversity of OS and platforms, plus mobile, a web-based solution is needed. Over the last several years, a cottage industry of threat modeling consultants and purchasable tools has sprouted up. The challenge with threat modeling consultants is that most of the ones I have encountered do not understand how to tailor threat modeling to a given enterprise. They teach a single, one-size-fits-all process. This approach makes developers mad because it does not directly apply to the software they build. I’ve examined the other tools on the market, and my complaint with them all is that they are too complex. For true enterprise adoption of threat modeling, any tooling that drives the process must be easy to learn and use. ### Enter the Threat Dragon As an industry, we are in luck, because there is a new open-source tool, just released to alpha, called the [OWASP Threat Dragon](https://www.threatdragon.com/#/). OWASP Threat Dragon is web-based and easy to use and adopt. This tool is the first real open-source product that can be used to make threat modeling a reality in all organizations. Mike Goodwin is the author of Threat Dragon. Here are his three primary objectives for this tool. #### 1\. Provide a great user experience that is simple to use. To be adapted to any industry, the UX has to be great. #### 2\. The tool will contain a threat/mitigation rule engine. This is important because the rule engine is how you make a threat model useful to a developer who has no knowledge of security. You have the developer draw a picture of something he knows (his feature), and then use the rule engine to “detect” potential vulnerabilities and suggest them to the developer. The rule engine teaches the developer how to detect security problems in design. #### 3\. Integrate Threat Dragon with other development tools. The aim is to provide developers with a cohesive solution for secure design and code. When you first visit the Threat Dragon page, you’ll notice that the only authentication option currently available is GitHub. This is because Threat Dragon is designed to store your threat models with your existing GitHub projects. The idea is that threat models are stored close to the final code so they can be considered when creating new features or updating an existing feature. ### How you can get started with Threat Dragon Your first step as a Threat Dragon modeler is to create a threat diagram. That's just a simple data flow diagram that shows how information moves from the external side (userland) of an application, and how it flows into the internals of an app. The threat diagram is kept simple by providing only process, data store, actor, data flow, and trust boundary for you to use to draw your feature. We can thank Microsoft for defining this simple set of shapes in its Threat Modeling tool. After you are happy with your diagram, you begin the process of identifying threats. Because this tool is still in alpha, the rule engine has not yet been coded. This does not stop this tool from being useful, though. STRIDE is a fundamental set of possible threats (Spoofing, Tampering, Repudiation, Info Disclosure, Denial of Service, and Elevation of Privilege). Even in its current state, you can create threats from those categories on your threat diagram. In the future, the rule engine will do much of this heavy lifting for you directly. ### Threat modeling gets real OWASP Threat Dragon is in its infancy, but it has the makings of a powerful tool that is still easy enough to teach to an entire army of developers. Threat Dragon is poised to quickly overtake the industry as the best possible choice for threat modeling. With the release of the OWASP Threat Dragon, there is now a threat modeling tool that can be adapted to any industry. I look forward to the opportunity to roll this tool out across an entire organization and make my dream come true. --- ### A security practitioner's guide to software obsolescence - URL: https://kerrsecure.com/2022/08/29/a-security-practitioners-guide-to-software-obsolescence/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo Unlike wine and cheese, the software does not get better with age—in fact, its security strength decreases over time. This is because of software obsolescence.  The problem is more significant than any other software security issue because it includes all the other liabilities. Take [the OWASP Top 10](https://owasp.org/www-pdf-archive/OWASP_Top_10-2017_%28en%29.pdf.pdf) [](https://www.microfocus.com/en-us/assets/security/developers-guide-to-the-owasp-top-10-2017)as an example. The list contains the most prevalent application security risks, and one (A9) is "using components with known vulnerabilities." And those components can introduce every other risk on the OWASP Top 10, including injection (A1), broken authentication (A2), and sensitive data exposure (A3).  Could a piece of third-party software be so old that it no longer attracts the attention of attackers? This occurred with Heartbleed, for some products. They were not vulnerable to Heartbleed because they were running a version of OpenSSL so old that it did not have the heartbeat code included. But antique libraries are a double-edged sword, because what other vulnerabilities lay within an early version of the software? This is a third-party software world, with software consisting of libraries that are strung together into a solution. The software supply chain is the journey your application goes through—it includes all the components you rely upon to build your solution. The 2019 State of the Software Supply Chain report by Sonatype exposes the depth of the problem. The report noted that each day, on average, there are 21,448 new open-source releases, with the average enterprise downloading 313,000 open-source components per year. The depth of the software obsolescence problem comes into focus with Java and JavaScript. One in 10 Java component downloads has known vulnerabilities at the time of download. JavaScript weighs in with a whopping 51% of components that have weaknesses. The downloading of known vulnerable components represents a severe challenge to the security of any application. It is difficult enough to detect a component vulnerability after you have deployed. If you start with a known vulnerable component during development, you are setting yourself up for an imminent software security failure. It's not a matter of if, but when. Another report, on [the state of open-source security](https://snyk.io/opensourcesecurity-2019/) by Snyk, is a continuation of the definition of the same problem. It found that 37% of open-source developers skip security testing, and the median time from when a vulnerability is found to when it's fixed is two years. Most popular Docker images contain, on average, 30 vulnerable system libraries. Software obsolescence is not going away. Here are the top tools and approaches for embracing it. ### Culture comes first: It's a journey Security culture dictates the emphasis given to security and is just as crucial for an open-source development project as it is for the team building out your application. From the open-source dev team perspective, as an industry, we must improve the general security knowledge of those writing the components. We must reach the point where 100% of developers feel responsible for the security of the elements they create. But impacting the open-source dev team is only a small portion of the solution. Many open-source groups do fix their vulnerabilities in a timely fashion, but those libraries are still downloaded and used by your development teams. From your development team's perspective, you must build a culture where each developer embraces software obsolescence and is continuously on the lookout. We must reach an era in which developers believe that even though they did not write the code, any vulnerabilities introduced are a reflection of their application and craftsmanship.  ### Exercise your codebase A secure development lifecycle must address software obsolescence and provide an organization-wide mandate and expectation for the update of the software. A stance of "the build will break if we have vulnerable components included within" is an approach that must exist to prevent software obsolescence. In a DevOps world, where software releases can occur hundreds of times per day, there is an advantage in that there is a daily exercise of a codebase. Tools can detect known vulnerable components and break the build until resolution. For those shops that are still trudging along at a slower pace, you need a process to exercise your codebase on a weekly cadence at a minimum to determine if any vulnerable components exist. ### Break your builds the right way Both commercial and open source technology exists that you can use to scan codebases and detect whether any known vulnerable software components exist within it. Source code repositories are gaining features that hunt for vulnerable parts in your code as it sits in the repository, and open-source tools are focusing in on this problem. Here are a few examples of tools and solutions for various languages and environments: - **[Dependency-Check](http://github.com/jeremylong/DependencyCheck)** is a software composition analysis utility that identifies project dependencies and checks if there are any known, publicly disclosed vulnerabilities. Currently, the tool supports Java and .NET; additional experimental support exists for Ruby, Node.js, and Python, and there's limited support for C/C++ build systems (autoconf and cmake). - OWASP's **[Dependency-Track](https://dependencytrack.org/)** provides an enterprise-scale solution and uses Dependency-Check as a source of input. Dependency-Track is an intelligent software supply chain component analysis platform that allows organizations to identify and reduce risk from the use of third-party and open-source components. Dependency-Track monitors component usage across all versions of every application in its portfolio to proactively identify risk across an organization. - GitHub provides an integrated service called **[security alerts for vulnerable dependencies](https://help.github.com/en/articles/about-security-alerts-for-vulnerable-dependencies)**. When GitHub discovers or receives the notification of a new vulnerability, it identifies public repositories (and private repositories that have opted into vulnerability detection) that use the affected version of the dependency. Then it sends a security alert to repository maintainers and generates an automated security fix. - Bundler-audit is a patch-level verification for the Ruby language. It checks the bundler package management system for vulnerable versions of gems in Gemfile.lock and for insecure gem sources. - NPM audit scans a Node.js project for vulnerabilities and automatically installs any compatible updates for vulnerable dependencies. When you execute npm audit, it submits a description of the dependencies configured in your package to your default registry and asks for a report of known vulnerabilities. The process with all of these various tool options is to install them and ensure that they break the build whenever they detect a vulnerable component. Force developers through your standard process to update sensitive parts. The [OWASP Component Analysis](https://www.owasp.org/index.php/Component_Analysis) page lists other commercial and open-source tools. ### Craftsmanship needed here The problem of software obsolescence is not going away, so change the culture, deploy the tools, and embed those tools into your process. Break the build when you detect a problem component. While the software build that breaks may be your own, that break may prevent the next significant front-page data breach. While no problem is ever easy, with hard work you can eradicate vulnerable parts. A focus on craftsmanship and the right set of tools will prepare your teams for success. --- ### A primer on secure DevOps: Why DevSecOps matters - URL: https://kerrsecure.com/2022/08/29/a-primer-on-secure-devops-why-devsecops-matters/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo I’ve been in the world of security for 20-plus years, I have seen trends come and go, but I’ve never seen anything as disruptive to the entire technology ecosystem as DevOps, often described as a methodology to build software fast and connect together development and operations. Gone are the days of tossing a build over the wall and hoping that it works in production. Now development and operations are joined together as one in DevOps matrimony. DevOps accelerates the velocity with which products are deployed to customers. However, the catch with DevOps is that it moves fast, and security must move faster to keep up and make an impact. I’ve spent the past few months on a journey trying to understand how security fits into the world of DevOps. What I’ve discovered is that most of the “experts” out there are just reiterating the statement that mixing DevOps with security is a good thing, without telling you how to actually do it. I’m scratching my own itch by diving deeply into the world of security with DevOps to figure out what this means and how to achieve it. Here are actionable findings on the processes and tools for [security with DevOps, or DevSecOps](https://web.archive.org/web/20230929112432/https://techbeacon.com/security/6-devsecops-best-practices-automate-early-often), while leaving the principles of security to others. ### Get your head in the game, appsec In the good old days, products were built under the waterfall process. With waterfall, the release cycle was measured in years, so the security process could take almost as long as it wanted. With the onset of agile development, things got speedier. Agile time is measured in weeks instead of years, and people stand up at meetings. The people can still implement the security process with agile because the pace is just slow enough. Face it, DevOps is here to stay, and it is not getting any slower. Application security must speed up to keep pace with the speed of business. Security automation is in charge under DevOps. DevOps is agile on steroids and feels like it is but without all the people. The people are still involved under DevOps, just in a different capacity. The people are not the process: The pipeline, the set of phases and tools that the code follows to reach deployment, define the process. The phases include build, test, and deployment. Build automation includes the tools needed to grab the code and compile it. Test executes the automated test cases, while deployment drops the build into its final destination. The people monitor the process and respond to process failures. ### Why all things continuous matters A perspective on DevOps begins with all things continuous. Continuous Integration (CI) is the principle that code changes are checked into the source code repository in small batches. With each check-in, the build system automatically checks out the latest version of code and goes through the build process. If the code that is checked in “breaks the build,” your changes get backed out and you get to figure out what caused the breakage. Continuous delivery and deployment are principles for how the results of testing are reviewed, and the system automatically makes the decision as to what to do with the build. With continuous, a set of tests is run and, if the code passes, the build moves to a staging environment. This is the point at which a human jumps into the process and manually makes the decision to push the new code into production. Continuous deployment is similar to delivery, except that testing is automated, as is the decision to push to production. There are no human beings in the build pipeline, so now you see why security must be automated, just like everything else in DevOps. ### The secret to secure DevOps: It's in the code There are two foundational principles you must embrace for the success of DevOps and security: security as code and infrastructure as code (IaC). Security as code refers to the building of security into the tools that exist in the DevOps pipeline. This means automation over manual processes. It means the use of static analysis tools that check the portions of code that have been changed, versus scanning the entire code base. IaC defines the set of DevOps tools used to set up and update infrastructure components. Examples include Ansible, Chef, and Puppet. Gone are the days of system administrators spending time fixing problems on a system. With IaC, if a system has a problem, it is disintegrated and a new one (or two) are created to fill the spot. ### Security is a cultural thing and a people problem In any process or methodology, people create vulnerabilities. Luckily, DevOps is also a culture thing. Teams do DevOps and live and breathe the culture behind it. The hinge to success for DevOps security lies in changing the underlying DevOps culture to embrace security—with no exceptions. As with any other methodology, security must be built into DevOps. #### Name confusion There's massive confusion across the security community as to what to call security in DevOps. People call it DevSecOps, SecDevOps, DevOpsSec, and even rugged DevOps. How can we have so many different terms to describe the exact same thing? This gives us a hint as to the disconnect that exists within security in DevOps. It’s still the wild west. There is no standard that defines security for DevOps, and the chances of a standard ever developing is small because different organizations are doing things their own way, and can’t even agree on a standard name. And while there is a standard for the secure development lifecycle (ISO/IEC 27034-1), few organizations are ever validated against it. ### DevOps + security is goodness Each of these terms refers to the same exact thing: the principles of how you apply security to DevOps. The term _DevSecOps_ appears to be seizing the day and mind share across Twitter and at conferences. DevSecOps is the current “movement,” with its own website and a manifesto. DevOps had the attention of the security community from almost the start—or at least from its infancy. DevOps + security is not easier than security for waterfall or agile, but it isn’t any more difficult. It is just different, and a heck of a lot faster. --- ### OWASP API Security Top 10: Get your dev team up to speed - URL: https://kerrsecure.com/2022/08/29/owasp-api-security-top-10-get-your-dev-team-up-to-speed/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo Marc Andreessen famously stated in 2011 that "software is eating the world." Now, in 2019, application programming interfaces (APIs) serve as the backbone of modern software, and they keep on devouring everything in their path, from microservices to single-page applications and mobile apps to the Internet of Things. APIs drive everything in the web world. But if the software is eating the world, then security—or the lack thereof—is eating the software. Hence, the need for [OWASP's API Security Top 10.](https://www.owasp.org/index.php/OWASP_API_Security_Project) [Erez Yalon](https://twitter.com/ErezYalon), one of the project leaders for the OWASP API Security Top 10 and director of security research at Checkmarx, has this to say about the state and prevalence of APIs: >  "APIs build today's software-driven world. ... APIs enable developers to write data-driven and flexible applications that all end users and organizations desire." But APIs are also creating a rapidly growing attack surface that isn't widely understood and is often entirely overlooked by developers and architects. [A recent report](https://www.gartner.com/en/documents/3834704) suggests that by 2022, API abuses will be responsible for most data breaches within enterprise web applications. [Additional research](https://www.gartner.com/en/documents/3955911) found that while 70% of enterprises cite APIs as crucial to digital transformation, securing them is a top challenge. > APIs are attractive to attackers because they remove the complexity of the many different front-end frameworks. In other words, APIs provide a standard interface on which to focus an attack. Here is a rundown of the new OWASP Top 10, with developer actions included for each item. ### Broken object-level authorization This is not an issue unique to APIs but is common in applications that are built in any language and perform authorization. APIs exacerbate this issue because the server component does not adequately track the client's state. This allows an attacker to modify an object's ID value and access other objects. The result is that attackers can access data that they are not authorized to access. #### Developer actions: - Examine/threat model your implementation of authorization policies and determine if an attacker can access items purely by knowing or guessing the object's ID value. - Marry random and unpredictable object ID values with a robust access control policy implementation. ### Broken authentication Broken authentication is another legacy top 10 issue (found in the [OWASP Top 10 for web applications](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project)). APIs suffer from the same authentication attacks, such as credential stuffing (where attackers try typical username/password combos in many locations) and brute force (where no restrictions by the API endpoint allow attackers to try all possible combinations for a username/password). One of the most significant issues with authentication in APIs is a total lack of it, or selective authentication, where it's not uniform across a collection of API endpoints. #### Developer actions: - Confirm a standard approach to authentication that is uniform across all of your API endpoints. - Review the authentication requirements within the [Application Security Verification Standard](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project) (ASVS) and apply these requirements to your authentication implementation. - Ensure that you have a strong business requirement before you expose an unauthenticated API endpoint to the public Internet. ### Excessive data exposure APIs are in the business of disclosing data to clients; that's why they exist. When you design an API, you determine who your clients are, and what information you will serve up for them. Excessive data exposure happens when you don't implement filtering correctly and end up sending more information than you should to a client. #### Developer actions: - Trace through/threat-model the information flows of data from the endpoint to the client and considers whether you have proper filtering in place. - Perform all filtering on the server side, not on the client. If you filter on the client, it can turn off the filter and receive all of the information. ### Lack of resources and rate limiting A finite set of resources serves APIs, and attackers can abuse an API by consuming all available resources, making the information service unavailable for legitimate users. Attackers consume resources both through the correct usage of an API—uploading many images, which generates multiple thumbnails and uses lots of CPU and memory—and by adjusting the API parameters to bypass filtering on the back end. #### Developer actions: - Analyze/threat model your design to determine whether you have proper rate-limiting controls in place. - Consider the [OWASP Automated Threat Handbook](https://www.owasp.org/images/3/33/Automated-threat-handbook.pdf) as a knowledge source for the many bots that are using your precious computing resources. ### Broken function-level authorizations These are terrible ideas, but they happen. With function-level authorizations, you're creating an individual micro-authorization policy that applies to a single function. What could go wrong with creating a unique strategy for every possible service? Complexity breeds vulnerability, and having separate policies for functions increases complexity tenfold. Disaster can ensue. #### Developer actions: - Use a standard approach to authorization that is uniform and set to deny by default; avoid function-level authorization. - Keep authorization simple; technology is already complicated enough. Securing something simple is hard; securing something complex is impossible. ### Mass assignment Mass assignment occurs when an API inadvertently exposes internal variables or objects. An attacker can craft an API request that provides values for an internal variable or object. If the endpoint does not correctly filter out those internal-only data structures, an external call may update an internal-only value. #### Developer actions: - Avoid exposing the internal variable or object names as input. - Whitelist the properties that the client can update. ### Security misconfiguration A security misconfiguration is a setting that could have been adjusted to lock down an API but wasn't. Security misconfigurations include neglecting security patches on the underlying application server or host systems, allowing all HTTP verbs, missing Transport Layer Security (TLS), missing security headers or Cross-Origin Resource Sharing (CORS) policy, and enabling excessive information flow in stack traces or error messages. #### Developer actions: - Perform a repeatable hardening process against your API, as you would with any other host or infrastructure system. - Test your entire stack for security misconfigurations using scanning tools and human reviews. ### Injection attacks Classic injection attacks such as SQL, LDAP, XML, and command injection are the most prevalent application security risks for web applications. #### Developer actions: - Perform input validation via whitelisting for all input. - Use a parameterized interface for all inbound API requests. - Review the filtering logic to limit the number of records returned. ### Improper asset management Improper asset management stems from a lack of version control for API hierarchies. APIs go through a lifecycle just like any other software, and versions of the API reach the end-of-life state. Older versions of APIs suffer from vulnerabilities eradicated from newer releases. Proper asset management calls for tracking where API versions live and retiring versions to limit legacy security vulnerabilities. #### Developer actions: - Inventory all APIs, including environments such as production, staging, test, and development. You can't secure what you cannot find. - Perform a security review of all APIs, focusing on the standardization of function. - Stack rank your APIs by risk level and improve the security functions of the riskiest items on the list. ### Insufficient logging and monitoring Logging and monitoring of data are crucial for deducing what happens when things go wrong. Logging and monitoring always fall to the end of any security list, because it's reactive even though everyone knows it’s essential. #### Developer actions: - Use a standard format for logging across all APIs; this makes life easier for incident response in the future. - Monitor your API endpoints across all phases (production, stage, test, dev). React to security issues identified within your API. ### How the API Security Top 10 Project started Yalon and [Inon Shkedy](https://www.linkedin.com/in/inonshk/), a security consultant at Tangent Logic, created this project to educate those involved in API development and maintenance: developers, designers, architects, managers, and organizations. Many different roles within an organization must understand how to secure APIs, and API security is more than just a code-level activity. It requires design and development working in tandem. Here is their perspective: "One of the biggest challenges when it comes to API security—or any security, for that matter—is awareness. The different ways of protecting APIs require an understanding of the actual threats facing modern applications, which is where we recognized a bit of a gap. "We launched the OWASP API Security Top 10 list to inform developers and security professionals about the top issues that are impacting API-based applications. Where APIs exist in nearly every form, prioritizing their security is of utmost importance, and the API Security Top 10 list looks to drive awareness and attention when it comes to their implementation." ### Don't let APIs eat your software's security APIs, just like software, are eating the world. The OWASP API Security Top 10 is a must-have, must-understand awareness document for any developers working with APIs. While the issues identified are not new and in many ways are not unique, APIs are the window to your organization and, ultimately, your data. If you ignore the security of APIs, it's only a matter of time before your data will be breached. --- ### The 3 most crucial security behaviors in DevSecOps - URL: https://kerrsecure.com/2022/08/29/the-3-most-crucial-security-behaviors-in-devsecops/ - Published: 2022-08-29 - Subject: Developers & Security Culture - Author: Chris Romeo What if I told you that you could change the security posture of your entire DevOps team without ever documenting a single line of a process? It's hard to imagine that's possible, but it is. Security behaviors take the place of the process and change how the developer approaches security decisions. In part one of this series, “A primer on secure DevOps: Why DevSecOps matters,” I discussed the importance of DevOps embracing security within its structure. The next logical question is, how do you transform a DevOps team into an army of security people? The answer is by modifying security behaviors. People are the true drivers of application security, and in the world of DevOps, people move fast. DevOps people are not allergic to process, but in my experience, DevOps is more about the build pipeline and automation than process. People believe that process slows everything down. But if you embed security change into everyone on the DevOps team using security behaviors, you'll empower everyone as a security person. The three core security behaviors you need to instill include threat modeling, code review, and red teaming. Each behavior is highly dependent on human beings. Tools are available to support each behavior, but the primary delivery agent is the human brain. Each behavior requires learning and practice. These are not things that a development team will do without direction. ## Threat modeling **Security behavior:** Consider the security impact of each design decision, and think like the attacker. **Desired outcome:** Choose the design decision that protects the confidentiality and integrity of your customer’s data. **Metrics to measure efficacy:** How many issues are you detecting and fixing prior to committing the code, and is the security light bulb turning on when the developer sees the impact of finding the weaknesses in the design. Threat modeling is about examining a design (or even code, if code is your design) to understand where security weaknesses exist. Threat modeling pinpoints how an attacker will attack your design, and highlights the places most likely to come under attack. With a threat model, you attack your product on paper and fix those problems early in your development process. Many DevOps practitioners approach the design phase with agile-colored glasses. They design in terms of user stories or features and focus on getting the feature to build and operate. Code takes the place of traditional design time activities. This is a challenge because security can be left behind when your primary focus is to get code running. After the developer has applied threat modeling behavior and considered security for each design decision, they can embed security directly into their decisions, and move toward a more secure option every time. **How to make it a habit:** Show developers how to create a threat model, and quickly move to threat modeling an active design on which they are working. Move quickly from the theoretical to the real-world feature. ## Security code review **Security behavior:** Detect security flaws in another person’s code. **Desired outcome:** Find the errors in the code that could be exploited if they reach production. **Metrics to measure efficacy:** How many security issues are you able to detect and fix prior to a build, promoting from test to production, or in a specific period of time. A code review is a critique of another developer’s code by searching for problems. A security code review is a bit more refined. It's deeper than just looking for logical flaws. The practitioner must understand the common types of flaws (OWASP Top 10 for Web Apps or Buffer Overflows for C), how to detect them, and how to fix them. Many teams are already doing code reviews, but the developers are not knowledgeable about security, and they're unable to find security flaws. Strong DevOps teams use their infrastructure to force code review with each check-in to the main line. I’ve heard of teams that use the built-in functionality with GitHub that only promote a change if another engineer on the team has given a "+1," indicating that they reviewed and approved the change. Static analysis tools offer a way to scan code changes and perform automated code reviews. These tools should not replace the human connection during your code review. Static analysis alone can't find all the problems in your code. Knowledgeable humans can detect logic problems that tools aren't smart enough to find. But do use static analysis tools to enable a more effective code review. **How to make it a habit:** Force a security code review as a requirement of the code commit process. Require a security +1 for each check-in. Teach your developers the fundamental security lessons of their languages, and how to find those issues in code. Finally, make static analysis tools available as part of your security tool package. ## Red teaming **Security behavior:** Attack your code with the same ferocity the bad people will apply to it when it reaches production. **Desired outcome:** Uncover flaws using active testing, fix those flaws, and push the fixes to production as fast as possible. **Metrics to measure efficacy:** How many legitimate issues are found and fixed because of red teaming efforts within a set amount of time? The idea of red teaming began within the military, as a way for a group of people to imagine alternative situations and then plan how to respond. Within the context of security and DevOps, a red team refers to the idea of having people who take on the persona of an attacker and attempt to compromise the code. Enacting such behavior means everyone on the team is always watching for some part of the product to compromise. Some teams approach red teaming by having people spend a portion of their time doing security testing, while others can justify having a dedicated red team resource that's always attacking the code. The key to red team security behavior success is that nothing is ever off limits. When the code reaches production, attackers shouldn't consider anything to be out of bounds. People enacting the red teaming behavior must be given the freedom to try any type of attack, regardless of the potential outcome. As a word of caution, you can always point the red team resources to a staging version of the pipeline to protect your production instances. The point is to never say “that could not happen” or “nobody would ever attack that way”. If your team can think it up, then so can others. As with the use of static tools in the code review, red teaming can incorporate dynamic analysis tools that scan for web application vulnerabilities as well as network and other infrastructure patches that are missing. These tools do not replace the knowledge of humans but can find some of the easiest issues quickly. **How to make it a habit:** Instill the idea that your code will be attacked, and provide the time and tools for everyone to spend some amount of time attacking the code. ### Why security behavior matters The traditional path to embracing security has historically focused on the process. You list a series of steps and expect everyone to follow those steps to ensure a secure solution. The challenge with that process is that it breeds _compliance,_ which means that someone improves security because they are forced to do so, not because they want the system to be more secure. Compliance provides some benefits, but it will never be as good as having developers change the way they think and embrace a security mindset. With compliance, people put forth the minimum amount of effort to check the box, and that results in minimal security gains. To keep up with the pace of DevOps and mix in security, you need to approach things differently. You should leave behind the security process, and embrace the idea of security behaviors. If you can change security behavior, then any time your people reach a decision point, their programmed response for better security will kick in. The idea for a set of lightweight and scalable security behaviors hit me while performing an application security assessment for a startup. The company had a mature DevOps process, and I soon realized that traditional application security practices were not going to work in its environment. A security behavior focuses on the lightest touch points, while still having an impact on security, and is the foundation of a true security culture change for a DevOps environment. ### How to set the tone for security behavior A good way to embed these behaviors within your team is to educate team members about the behavior, and then quickly move to its practical application. Encourage the activities and reward the team for completing them. The idea is to reinforce the positive behavior with the goal of evolving the security behavior into a habit. True security culture change is reached when the behaviors begin to transform into habits. A security habit is just a security behavior that has been practiced over and over and has become ingrained in the way the developer thinks. --- ### A developer's guide to attacker motivation in the supply chain - URL: https://kerrsecure.com/2022/08/29/a-developers-guide-to-attacker-motivation-in-the-supply-chain/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo Face it. Your software supply chain is under attack. You'd have to be hiding under a rock or in a bunker under the sea not to realize it. From SolarWinds-style attacks to language-specific repositories, supply chain compromises aren't going away—they're rising. Do you understand why software supply chain attacks are increasing? Have you internalized the attacker's motivation to pollute your software supply chain and embedded this knowledge within your security culture? Ending supply chain attacks requires awareness of why attackers pay attention to these types of attacks. To understand attacker motivations, stop and ponder the threat actors and their motivations. Due to the complexity of the software supply chain, threat actors will play differently in each scenario. Here are three case studies to illustrate, so that you can mitigate. ### 1\. Plain web application or mobile vulnerability The basic exposure, in this case, arises from a known issue in an open-source package or library that is reported via CVE. A tool such as npm audit or OWASP Dependency Check throws an alert that there's a problem. This issue likely appears somewhere on the OWASP Top 10 and should have been easy to avoid. The exploit is possible when developers don't update the package for some period of time, which could be weeks, months, or, in a worst-case scenario, years. The attacker's motivation in exploiting a plain vulnerability is to gain access to a web application and then complete a data breach in order to exfiltrate data to some attacker-controlled location on the Internet. Attackers breach data to sell it on the underground market for a profit, and such attackers are most likely cybercriminals. #### Mitigating factors: - Software composition-analysis tools quickly detect known vulnerable code issues. If you don't have one, get two of these and place them in your secure software pipelines: - [OWASP Dependency Check](https://github.com/jeremylong/DependencyCheck) for scanning, and [OWASP Dependency Track](https://github.com/stevespringett/dependency-track) for managing open-source and third-party risk using a software bill of materials ([SBOM](https://owasp.org/www-community/Component_Analysis)) - [Npm audit for Node.js](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities) - [Retire.js for JavaScript](https://github.com/RetireJS/retire.js) - [Bundler Audit for Ruby on Rails](https://github.com/rubysec/bundler-audit) - [Python Safety](https://pypi.org/project/safety/) - Maintain a healthy dose of skepticism toward the security of open-source and third-party software that your team includes in your software. Remember, while it may not be your code, it is your problem when a vulnerability strikes. Customers don't care that a vulnerability in your application was in a package you included. If your name is on the application, the vulnerability is your problem. ### 2\. Compromised build pipeline In the second case, an attacker profiles and discovers a weakness in your software build pipeline. The flaw could be because your pipeline is exposed to the public Internet (gasp!) or because the attacker was already inside your internal network and pivoted to focus on the pipeline. The attacker's motivation is to plant a weakness in your software build. After it is downloaded and installed at a large number of organizations, the attacker connects to each of them using the planted vulnerability. The level of coordination and preparation for this class of attack usually suggests a nation-state attacker—funded and resourced sufficiently to gain access to a software producer's internal network and orchestrate a pipeline compromise. #### Mitigating factors: - Harden your build environments against attack. Your build environment should be one of your most well-protected systems. Unfortunately, many build environments still suffer from the notion that, since they are contained inside the firewall or as part of the internal network, they don't need much additional security protection. - Generate and distribute an SBOM with any software that you compose. An SBOM is an ingredient list for your software and offers transparency to your customers about the contents of a given release/build. ### 3\. A malicious package sneaked into a repository In the third case, an attacker sneaks a malicious package into a language-specific repository. The attacker's primary purpose is to get that version of the package downloaded and embedded into many production applications in order to do crypto-mining attacks: A malicious package contains extra code that connects to a central service and receives a workload for processing. The attacker uses the compromised systems as a cluster to mine cryptocurrency. We've been lucky that malicious package attacks have not been more destructive or damaging. However, nothing prevents an attacker from using a malicious package to establish a back door (case study 2) or perform a data breach (case study 1). It's only a matter of time. #### Mitigating factors: - Use SCA (see above) to detect malicious packages (only works after someone has discovered the issue without an SCA tool). - Establish a set of package questions for every developer to ask and answer. If a prominent package has recently had a new package maintainer take complete control of the package, that is a giant red flag of a potential compromise. - Use an internal repository and vetting process that controls how new versions get to the internal package. This is a bit of a chicken-and-egg problem, because immature programs don't have the resources or know-how to vet packages, but you must strive to get there. ### The best mitigation: Awareness The software supply chain carries with it a certain amount of danger. You're essentially relying on the software created by people who don't work for you, many of whom are working for free. If you simply trust these people and projects, you may escape unscathed, but that's not going to last forever. If you've avoided software supply chain attacks so far, you've been lucky. The mitigating factors discussed here will help, but the best mitigating factor is awareness of the inherent risk in the software supply chain. Make sure everyone within your organization has that awareness. The package you patch or the pipeline you harden may be the one that blocks a crippling supply chain attack. --- ### 4 steps to transforming developers into security people - URL: https://kerrsecure.com/2022/08/29/4-steps-to-transforming-developers-into-security-people/ - Published: 2022-08-29 - Subject: Developers & Security Culture - Author: Chris Romeo Developers are everywhere because software is everywhere. Try to think of an organization that doesn’t employ at least a few developers to maintain their code. The challenge with developers is that most are not security people. By "security people," I don't mean that they need to be lifelong security enthusiasts that live threats and love firewalls. They just need a foundation in application security. Deep down inside, they want you to teach them. The primary problem with software is security vulnerabilities. Vulnerabilities are easily traced back to a bad decision made during coding and could span all the way back to a bad design decision. Vulnerabilities exist because of a mistake made by the developer at some point in the past. Vulnerabilities continue to rise because history repeats itself as developers commit the same mistakes, over and over again. The reality is that our applications live and die through ten simple things, outlined in the [OWASP Top 10](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project). The problem is that most of your developers do not understand enough about security to modify their behaviors to prevent these problems. Why is security such a stretch for developers? Because the average developer lacks understanding of the real ramifications of their decisions. This is clouded by the fact that developers are sometimes stubborn people who think they already know all that they need to know. In actuality, they do not understand the vulnerabilities that open up within their application when they fail to use parameterized SQL queries (SQL injection) or forget to validate _all_ input (think cross-site scripting). That lack of understanding is not deliberate. It is just that most developers have not been taught the foundational lessons of application security. > **Developers are not monsters. They want to do the right thing. The main problem they have is that they do not know what the right thing is for application security.** Reaching your developers with the message of security requires a four-phase process of application security connection. Open their eyes, fill their brains, task their hands, and embrace the gathering to truly get your application security program moving forward with developers who understand the foundational lessons of application security and how to apply those lessons in their code. ## 1\. Open developers' eyes to security The first phase is to open their eyes. This begins with the concept of application security awareness. This is different from generic security awareness training, where you teach everyone not to click on links or allow tailgaters to follow them through the office doors. Application security awareness is a foundational layer that teaches the basics of application security, such as security vocabulary, the business case for security, and who the bad people are that wish to compromise your web applications. You start with a layer of awareness to frame the problem and open their eyes to the ramifications of the development decisions they make. By understanding these basics, developers are primed for the next phase, where you fill in more of the details. **Action item: Determine the basic, foundational application security lessons that you must impart to all your developers.** ## 2\. Fill developers' brains with app sec The second phase is to fill their brains. This process provides the next level of learning they need to apply application security to their specific role. Filling their brains begins with knowledge. Role-specific knowledge prepares them to make the right security decisions. If you have C and Java programmers, you’ll need slightly different lessons for each. They both need the fundamentals of secure coding, but with language-specific examples. Teach them the techniques they need to be successful, and always explain why they should care. Modern-day e-learning often misses out on the most important question in a developer’s mind: Why should I care about this? Answer the "why" question by demonstrating the ramifications of a lack of security. The second part of filling their brains is history. Developers tune out when you show an example of the latest vulnerability in OpenSSL, but if you provide an example from the product or web application that they support daily, they will lean in and pay much closer attention. Revisit the past to enhance the future, searching through your bug database to understand the types of security vulnerabilities that cause the most struggles for your organization. Empower your developers to fix the future by demonstrating what has gone wrong in the past and teaching them the methods for not repeating history. **Action item: Determine the individual development roles in your organization, and specify the specific lessons various types of developers need to learn.** ## 3\. Task developers' hands The third phase is to task their hands, which means giving them something to do. After you have imparted knowledge and history to your developers, they must translate that knowledge into activity to truly make it stick. The activity should be a set of real security tasks to improve the things they work on. To be meaningful, these activities must be personal and real. Nobody likes to do busy work, so ensure that the activities you specify make a difference. Activity is about cementing the behavior change that you have advocated in the first two phases. The activities may include things directly related to what they work on, such as creating a threat model for their design or executing a security test plan. You can also adapt the activities to encourage other behaviors you wish to model, such as mentoring junior folks in security or speaking in forums such as a team meeting all the way up to external conferences. **Action item: Generate a list of activities to improve the security of your offerings, and incentivize your developers to perform those activities to lock in their newfound security knowledge.**  ## 4\. Embrace the gathering The fourth phase is to embrace the idea of gathering. After your developers have the foundational knowledge, role-specific knowledge, and a plan of activity for security, they need a place to connect with other security-conscious people in your organization. A security community is the connection point where developers can meet with other developers to talk security and learn from one another, and also where they can connect with the security department. Both enrichment and encouragement exist when a true security community is born. If you are part of the central security team, partner with the developers to make life better for both groups. A security community can manifest with simple things such as regional monthly security lunches or a monthly company-wide security training meeting. It can also become more complex as your organization matures, including hosting a yearly internal security conference, where developers from across the organization gather to share their trials and triumphs.  **Action item: Strategically choose the right set of events to bolster your burgeoning application security community.** ## Doing the right thing Developers want to do the right thing for security. The real challenge is that they do not understand what that “right thing” is. To truly transform the developers in your organization, follow these four steps and you will start the process of transforming developers into security people. --- ### 6 application security lessons every team should study - URL: https://kerrsecure.com/2022/08/29/6-application-security-lessons-every-team-should-study/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo When you build a skyscraper, how important is the foundation? It's crucial. Built on a weak foundation, even the most luxurious skyscraper will fail over time. The same is true for your application security program. You must build a solid foundation of application security knowledge, experience, and tools to ensure that the applications or products you build are secure. You must embed the six foundational truths of application security within your development lifecycle. Application security has one overarching foundational lesson that every organization needs to apply: Build security in instead of bolting it on. The build-in versus bolt-on decision is as old as security itself. When security is bolted on, it becomes an afterthought, pushed off until after the product ships. To properly build application security, you must embrace it within each step of your development process. The following six lessons provide a strong foundation for your application security program. Within the world of application security, there are hundreds of items that could be added to this list, but in the interests of time and efficiency, the list that follows addresses only the items that provide the best return on investment and the strongest foundation. ## 1\. Don’t trust user input—ever Users are not bad people—or are they? Unfortunately, good users get lumped in with the bad apples. The software that you write must take input from somewhere. Software without input is just a loop to nowhere. The problem is that most programmers trust the source of the input and implicitly trust all data entering their application. This is a flawed approach. Bad people send input to your application just as good people do. The bad people want your application to do something you did not intend. When attackers discover a cross-site scripting vulnerability in your web application, they uncover a place where you accept input (perhaps via a form field) and do not validate that input to ensure that it is JavaScript-free. That JavaScript input becomes output and results in an attack being either reflected into a legitimate user’s browser or stored up and unleashed on future visitors to your application. _**Tip: Perform input sanitization for ALL input, regardless of where it came from and how much you think you trust the source. Trust no one.**_ ## 2\. App sec, shift left (in the dev lifecycle) A secure development lifecycle (SDL) is a crucial process for your business. The SDL defines the process and tools required to ensure that every application you release has applied the necessary steps to maximize its security. Your SDL is an overlay to a more complex development process. The more security decisions you push to the left in your lifecycle, the cheaper application security becomes. [The National Institute of Standards and Technology (NIST) shares some advice](http://www.nist.gov/director/planning/upload/report02-3.pdf) (PDF) in “The Economic Impacts of Inadequate Infrastructure for Software Testing,” by stating that the earlier you find a defect in your lifecycle, the cheaper it will be to fix. A defect discovered in the requirements phase costs 1x to fix, versus a defect found post-release, which costs 30x to fix. This additional cost is due to all the rework that must occur after the fix is made. This advice seems like common sense, but it is not always so common. _**Tip: Embrace security from the beginning of your process and move application security left in your cycle. It costs less in the long run.**_ ## 3\. Default and hardcoded credentials are the enemies A default credential is a password or cryptographic key that is the same for all instances of your application or, worse, all versions of a specific product. If you use a default credential and it becomes publicly known, bad people could access any running instance of your software, regardless of whose network it is deployed within. A double whammy is to use a default credential and then hardcode it. If a credential is hardcoded, there is no way for the administrator to change the credential. A static, unchangeable password or key is a recipe for disaster. Developers use default credentials because they are easier than implementing a secure credential store that is unlocked at boot or runtime for a product. "Easier" in this case results in less development time but more risk for the product and the end customer. Eliminate default credentials to secure all of your users. _**Tip: Architect your product to force a password change during installation, and do not allow administrators to continue until they have chosen their own hard-to-guess password. Use a secure credential-storage system for your applications.**_ ## 4\. Responsibility for third-party software belongs to _you_ We are in the golden age of open source when you hardly have to develop anything on your own. Open-source libraries and application frameworks provide common code that saves development cycles and standardizes your approach. Even Stacktrace code snippets count as third-party code, since you may paste a stack trace dump into a code module with very little change. When you import third-party software, you are taking ownership of that code within your product. Third-party software suffers from the same potential vulnerabilities your own code suffers from. You must perform testing on third-party code as if you wrote it yourself. You must also update third-party code. Open-source software does not auto-update, and many products across the Internet suffer from running ancient versions of open-source software that have been forgotten about. _**Tip: Own all your code and care for it, regardless of whether it came from your brain or the Internet. Define a schedule to review and update any third-party software contained within your application.**_ ## 5\. Threat modeling reduces logic flaws Threat modeling is the process of looking at a design with a keen eye toward security and uncovering how bad guys could potentially attack it. Threat modeling causes you to analyze the design of your feature, component, or even your entire product. Threat modeling should happen before you ever write a single line of code. Threat modeling is done by the security team, who notes each available interface and dreams up ways to compromise based on the interface. The beautiful thing about threat modeling is that you do not ever have to craft exploit code. The threats are theoretical to help you pinpoint areas in the design that require a change to bolster security. Threat modeling begins with a diagram because a picture is worth a thousand words. The picture uses data flow diagram pieces, including a process and data store. The act of drawing the picture assists the developer with thinking through how a design will actually work. Once the diagram is sketched, then the security analysis begins. Your goal with threat modeling is to first teach it to your developers and then, over time, grow it into an ingrained behavior. True magic occurs when developers stop considering threat modeling a separate activity and perform security analysis organically. _**Tip: Build the habit of doing developer threat modeling. Threat modeling is basic application security hygiene.**_ ## 6\. The greatest application security tool: Knowledge Knowledge is the greatest tool available. When you prepare your developers and testers with the life lessons of security, you set them on a path toward squashing vulnerabilities early in the process. Application security tools are crucial to the success of any SDL, but their benefit is greatly diminished in the hands of an untrained engineer. As legendary software engineer Grady Booch said, “A fool with a tool is still a fool.” This may be a bit harsh, but it does crystallize the fact that you need engineers to be knowledgeable in all the fancy application security tools you are providing in your process. _**Tip: Teach your engineers about application security, and then provide the tools to optimize.**_ ## Keeping them honest on app sec If you apply these six foundational application security truths to your organization, you will improve not only your products but also the people that build and test those products for you. --- ### How developers can take the lead on security - URL: https://kerrsecure.com/2022/08/29/how-developers-can-take-the-lead-on-security/ - Published: 2022-08-29 - Subject: Developers & Security Culture - Author: Chris Romeo On the Internet, detection and reporting of vulnerabilities in software is a daily occurrence. Where do those vulnerabilities originate? Are they introduced into code by artificial intelligence or some advanced machine-learning algorithm? Nope. Human developers create them—mostly not on purpose, but by accident. They develop weaknesses because they lack the knowledge of what causes vulnerabilities and the responsibility for security. Security for developers is far more than just learning to hack. The security industry believes that hacking is the answer to every problem. Teach developers to hack, they say, and that will improve the security of applications. The sad truth is that learning to hack does not teach someone to build secure software. It shows them how to break their creation, which is a useful skill, but breaking does not result in building secure software. Here's how developers can take the lead on security in your organization. ### Developers vs. security teams: That is the question If developers are the source of most vulnerabilities, the first question to answer is, Should the burden of security fall on developers? There are two high-level answers to this question: Leave the security to the security people, or make everyone part of the security solution. The argument for leaving security to the security people is that developers are busy. They are experts in software and should be left alone to create beautiful things. This approach maximizes developer productivity and avoids burdening them with something outside their expertise. But it's almost impossible for security people to fix the security problems developers create without the assistance of those same developers. Creating a fix for something at a later time is always more expensive than doing things correctly from the start. And this approach does not scale when you get above 10 developers, because, for every 10 developers, you need to add one application security professional. An organization with 2,500 developers cannot support a 250-person application security team. ### All together now on security? The second option is to make everyone part of the security solution, including developers. On the one hand, developers are the software experts, and in the best position to secure the software they write. On the other, developers may spend time focused on things outside the scope of a specific user story or requirement. The shift-left movement, which pushes security as far to the left in the development lifecycle as possible, calls for every developer to focus on security. To achieve scale in an agile or DevOps context, security cannot be an afterthought. It must be embedded in the process and people. There is a great divide between the perception of developers and managers regarding application security. This divide is the result of a lack of education on the developer’s part. The most significant challenge to security education is that developer training focuses on the “what and how” of application security, and never explains why the developers need to care. When starting with “why” as a core question for every piece of information developers are expected to take in, they can understand the reasoning behind a concept and the ramifications if they do not follow the principle correctly. They know outcomes instead of just a set of steps or a tool that has no context in their development process. > The most significant challenge to security education is that developer training focuses on the “what and how” of application security, and never explains why the developers need to care. ### Let developers lead The short answer is that the burden of security belongs to developers. The idea that developers are unable to handle the details of security is crazy. A developer sees the writing of software as an art and a craft, not just a job and a paycheck. Developers exist in a whirlwind of new technologies. The creation of new frameworks happens yearly, and an active developer adapts to new technology. > The idea that developers are unable to handle the details of security is crazy The risk of not keeping up is obsolescence. The argument that developers are not smart enough or skilled enough to keep up with all the security jargon, tools, and design principles is not defensible. Developers are adaptable people by nature and will accept the challenge of security like any other challenge if you pose it to them correctly. Some fall into the trap of thinking that application security tools can solve all problems and prevent burdening developers. The investment of hundreds of thousands of dollars goes into providing the latest and greatest tools and draws the false conclusion that this will result in lowering the burden on developers and making the product or application secure. The challenge with this conclusion is that the tools by themselves require large amounts of care, feeding, and knowledge on the part of the developer for success. Application security tools are not plug-and-play. Take a static application security testing (SAST) solution. With SAST, the scanner reviews the source code, which results in a report for the developer. The report may contain anywhere from a few hundred to thousands of potential problems in the source code. Developers are just as burdened by the tool's output as they are by an extended security process. Tools are helpful for security, but they are not the answer by themselves. Since developers are the source of most vulnerabilities, security requires developers. The next question to explore is how much of the security burden developers should bear. > Tools are helpful for the security solution, but they are not the answer in themselves. ### Make security burden-free A burden-free security environment is an easy answer. When an organization has a strong security culture, developers understand the value of security and the risk of ignoring best practices. They know that personally identifiable information stored within the databases requires protection. A security system that is not burdensome to developers must follow a few common themes: 1. The result must have a low false-positive rate. Developers hate wasting time. 2. The system should integrate into developers' existing tools and not disrupt their flow. 3. The system should update all other resource allocation algorithms to provide a proper multiple of time for the developer to take on new security tasks. 4. It must have a defined, measurable return on investment. 5. The answer has something for developers as well as the company. Developers may never become experts in security, and that is okay. Building a secure product does not require developers to become security experts. But developers must share a common goal of securing any product or application. All developers must have a stake in the security of the product. ### Keep it about security culture A correct security approach should not place a burden on developers. If the focus is on building a positive security culture that rewards developers for learning and doing the right thing, then developers will not see it as a burden. But if you create a negative environment where mistakes result in punishment, your developers will never see security in a positive light. --- ### How to put the S (for security) into your IoT development - URL: https://kerrsecure.com/2022/08/29/how-to-put-the-s-for-security-into-your-iot-development/ - Published: 2022-08-29 - Subject: AppSec Programs & Practice - Author: Chris Romeo A joke about the Internet of Things has been shared around Twitter over the past few months; I saw it attributed to a guy named [Tim Kadlec](https://twitter.com/tkadlec). “The S in IoT stands for security.” Think about that for a second, and you’ll say, “Wait, there is no S in IoT.” That is exactly the point of Kadlec’s statement. IoT is missing security. This doesn’t have to be the case. There are no fundamental, groundbreaking reasons why IoT devices are not secure by default. The lack of security in IoT is a choice that developers have made. This lack of security is a tradeoff that was made between time-to-market and security strength. It is time for the industry to shift to a focus on security so that security is embedded within all IoT products. An IoT product is only as secure as its foundation. If security is approached in an ad hoc manner, then ad hoc results are all that can be attained. IoT developers must build security into everything, incorporating security early and often, from the time the product is dreamt up on a napkin or a whiteboard until the product reaches its end-of-life stage. Building security raises security to the same level as any other driver within the product. Building security into the IoT requires a standard approach to security. An industry standard for building security has evolved over the last 15 years, and it is called Secure Development Lifecycle (SDL). SDL provides a standard, repeatable process containing security activities that improve the security of a product. An SDL incorporates things such as security user stories, threat modeling, static/dynamic analysis, secure coding, and a product incident-response team. These activities have been validated as best practices through the experiences of the many companies that incorporate SDL. > To date, IoT development has been missing this standard approach to developing secure products. Here are key actionable areas for building security into IoT development. There are many more, but in my experience, a product must embrace these areas as the beginning of its security journey. The first area involves security user stories. These are just like regular user stories except that they focus specifically on security functionality in a product. Basic security user stories should be incorporated into IoT product development from the beginning of a project. ### Authenticate all services, regardless of how trivial With authentication, any entity attempting interaction with a system must prove its identity prior to gaining any access. Authentication is foundational; without it, it is difficult to control anything else on a platform. The IoT introduces a unique wrinkle with authentication. IoT systems deal in end-user communication and machine-to-machine communication. Both require authentication. End-user authentication can employ traditional username/password, certificate, or two-factor authentication. Strong machine-to-machine authentication requires a public key infrastructure and certificates that are deployed to each device within a system. In many IoT devices, there is no console, so authentication must be baked in and support the ability to update the credentials if needed, during the life of the product. ### Encrypt all data in transit using industry-standard, open encryption technology Encryption takes information that your customers send and receive through your IoT system and runs it through a mathematical formula to scramble it so that only those with a special key can unlock the data. IoT devices deal with data, and that data must be protected as it transitions from the device, across the Internet, and into the cloud. IoT devices need to incorporate industry-standard encryption libraries to ensure that the data is safe and secure during transfer. It can be tempting to think that, as an IoT developer, you have a better idea of how to scramble and transfer data securely, but it is best to utilize industry-standard, peer-reviewed cryptographic functions. You are not smarter than all the cryptographers on the Internet. ### Enable secure, automatic over-the-air updates to patch devices In the early days of the IoT, devices were created quickly, and some developers forgot a basic feature: a method to update the device after it reaches the field. It is crucial to provide a secure update mechanism. A secure update mechanism is one that receives a cryptographically signed update from the vendor and checks the signature of the update to ensure that it is valid and truly from that vendor. Vulnerabilities will continue to be found in IoT devices, and a method to patch those vulnerabilities must exist. The other catch with IoT devices is that in most cases, there is no console or user to perform the update. Updates must happen over the air, with no interaction required by the user. ### Manage and update your open-source software Open-source software is included in everything these days, and IoT devices are no different. A whole ecosystem has sprung up of open-source IoT platforms and libraries. IoT devices also rely on some of the same open-source software that web applications use, including libraries such as OpenSSL. Open-source software suffers from vulnerabilities at the same rate as custom-written code. The biggest challenge with open source is that many developers include it in projects and then experience amnesia when it comes to updating it. They rely upon the savings it generates without acknowledging that those savings upfront require work throughout the lifecycle in updating the libraries to a later version when issues arise. Generate an open-source update plan for your IoT projects and stick to it. Know what open-source components are included within your product and assign someone to watch for published vulnerabilities in those components. When a vulnerability arises, update the software, test the integration, and then deploy an update to limit your customer’s risk. ### Be wary of carrying over web apps' vulnerabilities The web app is the standard approach to administering an IoT device, but that means you inherit the web app's potential security vulnerabilities. Ensure that your developers are using vetted frameworks for their web development and are aware of the OWASP Top Ten. The Top Ten is an industry-standard list of the most prevalent risks to web applications, and these issues can manifest in an IoT admin app just as easily as in a standard web app. ### The IoT needs built-in security As the use of IoT devices continues to expand, the amount of data they contain also expands. Built-in security is the answer, but it must be a conscious choice. Developers of IoT must embrace security and security user stories. They must understand encryption and ensure that it is utilized. They must track their open-source software and ensure that it is properly updated. They must write admin interfaces that are not riddled with problems identified in the OWASP Top Ten. All of this is possible, with a focused effort on security. --- ### Information security needs community: 6 ways to build up your teams - URL: https://kerrsecure.com/2022/08/29/information-security-needs-community-6-ways-to-build-up-your-teams/ - Published: 2022-08-29 - Subject: Developers & Security Culture - Author: Chris Romeo Every application security and SecOps organization needs to connect people under the banner of security. The security of any organization is only as strong as its people, and people thrive in a community. So how do you build one? Developing a security community is about more than following a process or using a tool. It is about gathering together security-minded individuals in your organization so that they can share knowledge and experiences. A thriving security community can serve to teach, mentor, and energize new members on the benefits of having a security mindset. Members of security communities go by different names, but whether you call them security champions, advocates, or guild members, all are passionate about security and enjoy sharing their experiences with others. The activities below reflect the best practices that successful app sec and SecOps teams have used to connect and grow their security communities. The list starts with activities you can do that are relatively easy and least time-consuming. As you move down the list, the activities become more involved and require more resources. ## 1\. Monthly training and connection events A monthly training event is the bread and butter for any security community. This event forms the connection point for the members of the group to gather and learn something new from their peers. You can hold these events in person or through a web conference, depending on the geographic distribution of your membership. Session content should include a mix of security updates for your organization and cutting-edge training. When running such events in the past, I consulted my network and invited well-known external security researchers and consultants to present on a topic. The easy way to lock in more external speakers is to use web conferencing for your meetings so that they don't have to travel to your site to participate. I’ve had speakers share drafts of talks they planned to use at upcoming conferences, so our community received a sneak peek of content that had not yet made it into the public eye. To ensure success, keep your meetings low-key and lighthearted. I started my monthly events with a security trivia contest. We created questions based on a security-related topic and then asked people to type their answers into a private chat window. We ran the trivia sessions for the first five minutes of the meeting, giving latecomers a chance to connect before the actual meeting began. Over time, people began joining the meeting five minutes early to ensure that they were ready to play trivia. I awarded $50 Amazon gift certificates to the winners. The hardest part of planning this type of event is finding your guest speakers. Try to schedule speakers three to four months out to ensure that you have a full backlog. This helps you plan but also gives you a list of people whom you can ask to come earlier if you have a speaker cancel. ## 2\. Monthly vulnerability decomposition discussions A vulnerability decomposition discussion is similar in nature to the monthly training and connection event, but the focus is to break down the details of a specific type of vulnerability. I recommend scheduling this discussion once per month. Alternatively you could replace one of your monthly training and connection events with a vulnerability decomposition meeting once per quarter.  To prepare for the discussion, query your bug database from the past quarter and list the top category for security bugs. For example, your top item might be SQL injection. In the vulnerability session, present a description and technical details for SQL injection to ensure that everyone understands the issue, and then explore examples of SQL bugs that arose in the last quarter. Choose the bugs in advance, working with your response team to find the right examples. This event requires some up-front prep work. You’ll have to do some research in advance of this session: Searching the bug database and preparing to lead the discussion will take some time. But you can invite other senior members of your security community to assist in the preparation or even to lead the session. This is a great way for them to receive exposure and grow their abilities. ## 3\. Certified Secure Software Lifecycle Professional book-of-the-month club When you form a CSSLP book-of-the-month club, you invite members of your community into a study subgroup and then study a topic that results in certification, such as the CSSLP. This is an in-depth, fact-based certification for people who focus on software or application security. If you have a subgroup that is new to security, consider starting with the Certified Information Systems Security Professional (CISSP) certification instead. Either way, the leader of the subgroup chooses a book and coordinates signups for community members. The leader creates a schedule and then offers a lecture based on the schedule. An effective way to approach this is to use a certifications preparation book and then attempt to complete one chapter per session or a specific number of pages each month. It is important to spend plenty of time in group discussions, answering each other’s questions and clarifying points that might not be clear to everyone. Getting this activity off the ground is a bit more difficult: If you choose to lead this group, you’ll have to study each week in order to present the material and field questions on the subject. And while it does help to have the certification you are discussing, that's not mandatory. ## 4\. Security days A security day is a mini security conference that serves as a local connection point where the community can gather and network. This should be an in-person event that includes guest speakers from both inside and outside of your organization. If you work for a global company that has many locations, consider stringing together a series of successive security days around the globe. You can reuse the agenda and some of the setup and creative materials you prepared for the first event for subsequent security days. Your security day event should last no more than four hours and start either first thing in the morning or afternoon. This allows developers and testers to attend and still get in a half day of work before or after the event. During her talk at RSA 2016, Samantha Davidson of Uber referenced a security day where she brought in Rami Malek from the hit TV show _Mr. Robot_ to participate in a panel for the internal Uber community. _Mr. Robot_ is a popular show that spawns a quest for security knowledge among viewers, so it was a great connection point for the Uber security community. I'd put the effort required to pull this off at 7 out of 10. The logistical details involved raise the degree of difficulty of hosting security days.  ## 5\. Internal capture-the-flag hacking challenges Capture the flag, or CTF, is a hacking challenge event where individuals or teams work out challenges contained within a known, vulnerable system or network. When they complete a challenge, they earn points toward their total score, and the challenges become progressively more difficult as contestants move through the system. At the conclusion of the event, the leaderboard shows the teams that earned the most points, including the winner. A CTF is a nice platform for recognizing your more technical team members. The degree of difficulty involved in hosting a CTF event is quite high — I give it a 9 on a scale of 1 to 10 — because it's difficult to set up and monitor. However, there are vendors that provide managed, cloud-based CTF infrastructures that can host your game. And if you want to take on the challenge of creating your own environment, you can use Carnegie Mellon's [PicoCTF](https://github.com/picoCTF) or [Facebook's released CTF code](https://github.com/facebook/fbctf), available as open source.  ## 6\. Internal security conferences An internal security conference is the most complex item on this list to pull off. This multi-day event includes registration, training, keynotes, conference talks, vendor sponsor fairs, and social events. To prepare, you’ll need to host an internal call for papers and then adjudicate all the submissions. You’ll need to coordinate with many external speakers and sponsors, and you'll have hundreds of tiny logistical details that need to be worked out. The answer to a simple question such as “What’s for lunch on day one?” requires research and partnership just to pull off. If you get that answer wrong, you’ll have a line of hundreds of angry conference goers shaking their fists at you. There are three keys to successfully pulling off a conference. The big one is to give yourself adequate planning time. A two-day conference requires six months of prep time. Secondly, you'll need to build up a team to assist in the planning process. Finally, choose partners who will help you create a successful event, including facilities, catering, and administrative support. Take care of your partners and always treat them with respect, as they are the ones who you need to rely on to bail you out if something begins to fall apart. This is by far the most difficult community event to pull together. Be prepared to have a second full-time job if you take on the chairperson role for an internal conference like this. It is a mountain of work, but when you see the event delivered, you'll see that it's well worth it. If you wish to host an internal event but are scared off by the amount of work, consider hiring an event planner. That will offload the logistical details from your plate, and allow you to focus on the technical content and vision for the event. ## What does your community need? So there you have it: Six ways to engage your security community. Take these ideas for activities, adapt them, and make them your own. There is no cookie-cutter approach to community building. Each event you host should reflect your organizational culture. --- ### 4 ways to engage developers who couldn't care less about security - URL: https://kerrsecure.com/2022/08/28/4-ways-to-engage-developers-who-couldnt-care-less-about-security/ - Published: 2022-08-28 - Subject: Developers & Security Culture - Author: Chris Romeo You would think that there is not a single developer on earth who has avoided the impact of a data breach or security vulnerability. That should cause every one of them to focus like a laser on security. Unfortunately, this is just not the case. Everyone, developers included, has become numb to data breaches. This numbness can be overcome when a development team gets fired up for security. Perhaps they receive a security spark from their executive management or a customer. Or, in the worst case, they experience a security vulnerability or breach, and everyone finds security religion. But what about the opposite end of the spectrum, when a development team looks you in the eye and says, “We do not care about security.” That is a difficult challenge to overcome because their reasoning has some merit. They say things such as, “Security is a cost that we cannot afford to pay. We must ship the next release, and the ship date is non-negotiable.” This team does not care where the directive came from. “Tell the CEO we said that we must ship the release because we promised the customer.” They have a point, but do they have a real excuse? ## Waking developers up to their reality This challenge is not the end of the world. All people have some amount of reasonableness inside, no matter how far down it is buried. We just have to burrow down and connect with them and cause the security light bulb to go on for them. I’ve had this experience numerous times during my career as a security evangelist. I’ll go in to work with a team that says they don’t do security or don’t have time, or any of lots of different excuses. I’ll begin to work with them, teaching and mentoring, and slowly pointing out flaws in their application. I teach them the process that I use to uncover those flaws. The security light bulb goes on when they suddenly realize the magnitude of the threat and the inherent risk in the development choices they make. From that point forward, they are changed, and they no longer rail against security but become staunch supporters of all things security. To connect with the development team that puts their hand in your face, here are four specific things you can do to sway them to the security cause. ## 1. Start with why security matters Simon Sinek has a great book titled _Start with Why_. As folks with a passion for security, we all too often jump into teaching security by focusing on the bits and bytes of input validation and output encoding. All that the average developer with little security experience hears is that we want them to do more work with the same amount of time they had before this “security thing” became popular. The way to combat this attitude is to explain the “why of security.” Why do they need to care? What are the ramifications if they choose not to? I like to use examples from everyday life. What happens to an air-traffic control system when security is not a priority? How much effort do you think the company that manages the data for the office of your child's doctor should put into securing their applications? Your kid’s personal health information is worth something, right? Drawback to why developers need to care, and that will connect with some of them. Land the plane on this conversation by circling around to the customer requirements for security and the impact to the customer if data is breached from your system. ## 2. Determine what motivates the team Everyone is motivated by something: money, power, fame, or influence. You need to determine what motivates this development team. Is it a chance to have a party at a restaurant on a Friday night (a team-building event)? Is it cold hard cash in their pockets? Some teams love custom T-shirts. Use whatever motivating factors influence this team to entice them to learn about security. Motivation via rewards and recognition is a connecting point with any team. Once you discover their motivation, build a learning program to reward the team for hitting milestones. Perhaps one milestone is having everyone watch an initial set of video modules together over lunch (provided by the company), one per week, and then participating in a discussion for 30 minutes. At the conclusion of the six weeks, there is a special team-building event to celebrate the fact that all of the team members increased their knowledge. If your executive management team is pinching pennies at the moment and challenges you that this expense is not required, explain that a single breach of your systems will cost a thousand times more than a lunchtime security learning series. You must partner with your executive management team. They control the purse strings. Ensure that management is on board with the motivational plan and will fund it. If management doesn’t support the concept of securing the product to improve the customer experience, it will be difficult to get the team on board. Do not try to achieve better security by having management pass down a security mandate. Mandates breed compliance, and compliance is not security. Compliance is checking a box. True security requires changing how humans approach securing the product. ## 3. Throw in a bit of custom gamification Gamification is applying to other parts of life the principles that make video games successful and addictive. Set up a series of events for your development team to do and choose a theme for the event. Theme, you say? This isn’t college, and no, I’m not suggesting a toga party (unless that works at your company.) Talk to members of the development team and find out what they like to do or what they watch on television. Are they _Game of Thrones_ fans? Uber did a [whole security awareness campaign using _Game of Thrones_ as the theme](https://web.archive.org/web/20170228013232/https://newsroom.uber.com/us-new-york/the-ride-of-thrones/). It created teams named after the houses of _GoT_ and awarded points for good security hygiene. Connect with a topic that the team is into, and layer security on top of it to connect with them. Gamification adds fun to the mix, and who doesn’t like to have fun at work? Gamification connects fun with security. ## 4. Begin with the foundational lessons To win this team over from the dark side, you need to begin to familiarize them with the foundational lessons of application security. After you have them kicking the tires because you’ve laid out the why, determined their motivation, and created a game-based experience, teach them the basic vocabulary of application security: attack, threat, exploit, and vulnerability. As the team begins to learn the basics, they will pay more attention to the security news that they hear every day. Next time they hear of a SQL injection vulnerability that resulted in a data breach, they will be more likely to want to learn additional details about SQLi. Success in reaching any development group is a programmatic affair. Start with the why, explore motivation, make it a game, and then teach them the foundational lessons. You’ll get to the end of step four, and you’ll realize you’ve connected with them because you took a step to walk a mile in their shoes. --- ### Why developers dislike security—and what you can do about it - URL: https://kerrsecure.com/2022/08/28/why-developers-dislike-security-and-what-you-can-do-about-it/ - Published: 2022-08-28 - Subject: Developers & Security Culture - Author: Chris Romeo Developers dislike security but won’t always admit it. They dislike the security function because it doesn’t understand development and often tries to force a process and toolset on them. The tension between devs and the security teams regarding the security of new features and bug fixes is called “the DevSec disconnect.” If you imagine a developer who is about to push a feature, you can almost read his thoughts: “Security is getting in the way and slowing us down. They have arbitrary requirements and can’t make up their minds. We need to push this feature to production.” On the flip side, security says, “The developers are lazy and are not applying the guidance we provide via the process and the pipeline. Their code is insecure; our tools blow up when we scan the code. They can’t push this feature to production.” The DevSec disconnect is real, and it stems from a lack of understanding between the parties. Empathy is the foundation of the answer to closing the DevSec disconnect. Empathy is psychological identification with another person or vicariously experiencing that person’s feelings, thoughts, or attitudes. When security professionals feel empathy for developers, they are able to understand the struggle necessary to implement security while still pushing features and bug fixes into production. With empathy, security teams truly experience developers’ frustrations, which leads to better working relationships. Here are 10 frustrations that developers have with security, with a resolution and actions that security can take to counter each. ### 1. “Security doesn’t understand what I do.” If you take your car for service, do you tell the mechanic how to fix it? It is frustrating for developers to be instructed by those that do not know how to do what they do. But coding skills are one of the 5 core skills every cybersecurity pro should possess. A security person who doesn’t invest the time to learn how to read and write code is saying, “I’m important enough to govern this process, but not concerned enough to understand the work you do.” That is consulting without expertise. **Resolution:** Become a developer and learn how to code. **Action items:** 1. Learn the primary base language your developers use. Your code review skills significantly increase when you build a foundational knowledge of at least one object-oriented language. 2. Understand and be able to explain the build pipeline from a developer perspective. 3. Explore any frameworks in use and understand how they work and add value. 4. Write and commit a small amount of code alongside the devs. Use the process that you have spelled out for security; you might be surprised by the amount of friction you encounter using that process. ### 2\. “Nobody ever showed me how to do security.” Your developers’ knowledge and experience with security may be lacking. Security people expect developers to react and do the right thing, but they have no idea what the right thing is and nobody has taken the time to spell it out. If a security person tells a developer, “Stop coding SQL injections!” the developer is likely to think to herself, “What’s a SQL injection?” Developers are frustrated when you do not take the time to teach them the foundational pieces of security. **Resolution:** Build a security coaching practice and education program. **Action items:** 1. Define and document how to coach for security. 2. Empower your security team members and champions to perform coaching. 3. Roll out an education program that touches every adjacent product person. ### 3\. “I don’t know why we put so much effort and time into security.” Developers are compensated in most organizations for producing features and fixing bugs. The security team is always (rightfully) preaching the need and value of building secure things. But security fails when it doesn’t explain the value proposition and the return on investment that comes from shifting left, or moving security to the earliest stages of development. **Resolution:** Start with the why and the security ROI. **Action items:** 1. Launch a campaign to promote the three R’s: reputation, retention, and requirements. If the company's **reputation** for security is poor, it loses customers (**retention**). Customers levy specific security **requirements** based on regulations or their internal security culture. 2. Analyze the data and give developers objective metrics for security ROI. They can be motivated to change by metrics such as the percentage of flaws that require rework. That's because they want to build new things, not fix problems with something they made weeks or months ago. ### 4\. “The security process is difficult or undefined.” Without clear guidance and a framework, developers are unsure what the process looks like or what the requirements are for them and new-feature development. Developers crave predictability of the surrounding process. Without that, they won't know how much time they will need to set aside for the security process when marching toward a Friday deadline. **Resolution:** Use the secure development lifecycle (SDL) as guardrails. **Action items:** 1. Lean into the SDL, and if you don’t have one, get one quick. 2. Give developers the freedom to be creative by sharing the SDL with them. 3. Define and communicate clear developer expectations regarding the SDL and other security processes. ### 5\. “Security people change their minds all the time.” Developers can have this perception if they see security telling two teams different things. From the security team's perspective, those different answers are entirely appropriate and accurate. But for the developers, the issue is trust. Developers lose faith when advice isn't consistent, and a developer who loses confidence in security will stop bringing things to security’s attention. **Resolution:** Fully explain answers and suggest getting a second opinion. **Action items:** 1. When interacting with developers, never assume that you have been understood; perspectives can be too different. Question the level of understanding until satisfied that it is sufficient. Ask developers whether they agree with your conclusion, and discuss in more depth if they do not. 2. Ensure that your team is doling out the same guidance. 3. Provide a mechanism for developers to get a second opinion. ### 6\. “I can’t please everyone.” Developers are under pressure every day to fix bugs and deliver features. When their manager has not bought into the corporate requirements for security, they are pulled in two directions. To comply with what security has decreed, they must go against the immediate orders of their manager. **Resolution:** Raise awareness about security resource needs. **Action items:** 1. Gather buy-in for security resource allocation at all levels: front-line managers, directors, and executives. 2. Provide estimates for how much time the average security activity takes for completion. 3. Launch a campaign to make everyone aware of the need to communicate about security resources. ### 7\. “Security is a silo and acts as a gatekeeper.” DevOps promotes open communication among everyone on the team; siloed security operations are alien to developers because they block flow and hamper communication, requiring more status meetings to stay in sync. Security also wants to make all the decisions. Gatekeepers are frustrating because their need to control the process slows down everything to a crawl. **Resolution:** Partnership, not gatekeeping. **Action items:** 1. Just let go. Build an automated process and rely upon it for success. 2. Perform a proper assessment of gatekeeping. Ask your developer audience if your process has any hint of gatekeeping. 3. Partner with your developers. ### 8. “Security gives us busy work.” Developers need to see value in the activities that security asks them to perform. When security requires a risk assessment for every new feature but never reviews the risk assessments, developers will be frustrated that you are wasting everyone’s time. If you are doing anything manually (except for threat modeling), you are wasting some time. It is frustrating for anyone to do busy work of any type. **Resolution:** Optimize the process, and no busy work. **Action items:** 1. Review all the artifacts from your process and collect feedback from developers and security about which ones maximize value. 2. Cancel any artifacts that are not useful in the improvement of security and privacy. ### 9\. “The sky is always falling—we never celebrate success.” By its very nature, security is always chasing the next vuln, problem, or bug, taking no time to celebrate or even pat anyone on the back. It is frustrating for developers to work in an environment where things seem to get worse every day. **Resolution:** Celebrate security wins. **Action items:** 1. Get a feel for the climate. Is the sky always falling for your developers, and is security the cause of this perception? 2. Celebrate security wins at different levels. E-mail and team chats can do a lot and cost almost zero. Other ideas are all-hands events and naming a security win of the month. ### 10\. “Security tools are loud, obnoxious, and inaccurate.” In security, we love our tools. We think they have nearly all the answers. But developers are frustrated when security tools generate thousands of entries and false positives. **Resolution:** Tune the tools. **Action items:** 1. Assess the current frustration level with your security tool suites among your developers. 2. Practice the least possible configuration mode with any new tools or tools with a terrible reputation. 3. Don’t be afraid to yank a tool out of the pipeline if it needs revamping. ### Security culture and empathy are key Don't try to solve all of these frustrations at once. Review the list, consider which of the items are most applicable to your organization, and then start making programmatic adjustments to improve your security culture. Spend time getting to know your developers by practicing empathy. Walk a mile in your developers' shoes, and make the changes you need. You’ll have a company where developers and security work together, and when that happens, security culture starts to change. --- ### Why marketing security to your org matters—and how to do it right - URL: https://kerrsecure.com/2022/08/28/why-marketing-security-to-your-org-matters-and-how-to-do-it-right/ - Published: 2022-08-28 - Subject: Developers & Security Culture - Author: Chris Romeo What if we told you that as a security professional, a portion of your responsibility is marketing? You would likely tell us we are crazy. But both of us have experienced "aha" moments in our careers as security professionals when we realized that part of being a successful security person is knowing how to market ideas to the organization. All too often, security organizations neglect these foundations in place of technology, process, or compliance. It is natural. Most security experts start as technologists or risk specialists and drift back into their comfort zone. To illustrate this point, see if the story below sounds familiar. Acme Co. hires its first CISO, Tanya. She hits the ground running, meeting people and hiring a team. She meets with her peers and describes her vision. The team gets hired and promptly starts rolling out products and tools to match Tanya's plan. After an initial flurry of success in getting the organization aligned, things stall, as people stop implementing shiny new tools or following newly minted policies. Tanya is confused. She met her stakeholders to explain her vision. She has an email from the CEO saying security is essential. Frustration in the team rises. Fewer folks in the organization are using the tools or processes. Tanya resorts to the stick part of the carrot/stick and adds more punitive measures. Security team members start to leave, and stakeholders stop taking meetings with her. They are "busy." Tanya begins to feel that the organization doesn’t "get" security, and she eventually moves on. Sadip arrives as the next CISO, and the process starts all over again. ### Why marketing can help  Sadly, we would guess that most of you have been Tanya or worked in her organization at some point. Tanya would have had more success by taking a page from classic marketing techniques. And we know the reaction most security pros are going to have with this suggestion. Many technologists believe that marketing is a soft function that pushes out a press release and runs booths at conferences. But in reality, marketing is about two things: building sustained relationships with your customers, and expanding the reach of your business or program by being ever-present in the marketplace. People will get behind a change when they understand and believe in the concept. To get yourself in the right head space, start by thinking about relationships and reach. These two concepts are the foundation of any good business or program, from selling widgets to fundraising for charity to running a security program. ### The core marketing phases Here's a breakdown of the major phases of marketing and how they are relevant to a security team. #### Prep: Do your homework  Answer these questions:  - What business problem are you trying to solve? - Why is it important? - Who are your stakeholders, and why do they care? - How hard will the process be for your stakeholders? Do your research; these questions/answers will serve as the basis for your marketing plan. #### Exposure: Own the channels Potential or current stakeholders need to know that your security organization or activity exists. Security needs to "own" all the channels to drive exposure and movement to the next phase. One email is not going to suffice. You need a multi-channel approach—emails, wikis, blogs, seminars, and even video screens in the cafeteria. Everywhere you can broadcast your message. The key here is that this is ever-present. #### Discovery: Double down on reach Expand your message by directing stakeholders to content you have created that explains your organization and its activities. The key here is that you need good, relevant content. Do not skimp on this. Believe it or not, your stakeholders are judging your team based on what they see. For example, you have set up your program to static scan for XSS, while rolling out a training program and a marketing campaign to stomp out XSS in your environment. But the product you ship is not a SaaS website but a BOSE/SONOS speaker. While you are ticking a security box, you are not making it relevant to your audience, which is likely more interested in C++/firmware protections. Tailor the campaigns to your environment—not to check a box. #### Consideration: Understand stakeholders' needs Your stakeholders know about your team and services, but it is unclear whether they want to use either one. You must explain how a relationship with your organization meets the needs of your stakeholder. The key is "their needs," and not yours. You will not foster a long-term relationship with a stakeholder if it is all about you. #### Conversion: High-touch, low-friction onboarding The messaging is out there, stakeholders can discover more, and there is an alignment of needs. This conversion phase contains the most critical step as it sets the tone for the relationship going forward. Security teams need to be extra helpful at the beginning of the relationship ("high touch") and simplify utilization ("low-friction onboarding"). Simplification will pay off tenfold with connection and reach. Unfortunately, security teams frequently execute the exact opposite. The security team becomes low-touch ("We made the pitch and moved on") or high-friction ("The activity is way too hard to onboard"). #### Nurture your stakeholders If the goal is to build a long-term relationship, how is your team nurturing the stakeholders? How excellent is your team's customer service? Are you ever present with the stakeholder? The key here is to be the right partner. Communicate often and well, be responsive, and listen to what they say. Reach out to your internal customers on a prescribed cadence, perhaps once a quarter; be humble by adapting to their needs; and remember the old marketing adage, "It is much easier to retain a customer than to find a new one." ### Action items: How to get started in the real world Almost convinced? Here's a real-world practice that allows you to apply these concepts: security champions_._ A security champions program can magnify the reach, relationships, and resources of internal security teams. Security champions are individuals with an existing or newfound passion for security. The program provides a way to channel their interest and energy into positive security culture change for your organization. #### Prep The marketing challenge with security champions is twofold. First, you need to educate the entire organization about the availability of this new program that will make your organizational security posture better. Second, because you're asking employees to take a percentage of their workweek and dedicate it to this volunteer effort, you must market the program's value proposition. #### Exposure To gain exposure for security champions, start with an email message announcing the existence of the program to the entire company. Aim far and wide with this broadcast because you do not know where the next generation of security champions sits today. They could be in non-engineering roles. Your goal is to capture anyone with even the tiniest spark of interest in security.  After a broadcast approach for exposure, go grassroots. Start by setting up meetings with specific engineering teams and ask them to advertise the program during their all-hands and team meetings. Schedule sessions with small groups of developers and pitch them about joining the program. For example, when Chris was building a security champion program for a Fortune 100 tech company 10 years ago, he traveled to Silicon Valley. He went building by building, knocking on cube walls and telling folks about the existence of the new security champion program. In addition to building from the bottom, you will need to push from the top. Engage with senior leadership, brief them, and ask them to support this effort by sharing the message with their teams. #### Discovery Build a security champions site on your internal network and fill it up with relevant information that "sells" the program. - Create a presentation that a manager can download and efficiently deliver to their team as a recruitment tool. - Create pages that proclaim the charter of the program. - Document the value proposition to both the employee and the employee's manager upon joining; make it easy to read. - List via a roster of all the existing security champions. You want potential recruits to see this as a burgeoning group that they wish to join. - Provide a training experience to educate stakeholders about security and get people excited about the topic. #### Consideration You've moved past people knowing you exist and into them thinking about whether to become a champion (or whether to let their team member become a champion). At this stage, you need additional data for them to consume. This is where PowerPoint presentations come into play.  Craft the message to highlight how making this decision benefits the employee (growth in job role), the manager (more secure product), and the company (happier customers because products have fewer vulnerabilities). If some folks are considering, but need more of a push, you may have to set up individual calls and walk those people through the slides and answer their specific questions about impact. Take these calls and communicate. You'll learn and have the opportunity to update your materials to serve potential future champions better. #### Conversion A high-touch, the low-friction champion process has a team willing to take calls with folks and a simple/precise method of signing up as a champion. #### Nurture customer success and retention Once someone becomes a champion, focus on making them successful in that role. Create an onboarding process with specific, measurable goals over the first 90 days of each champion's time with the program. Provide specialized training only for champions, connect new champions to the monthly champion meetings you host, and identify a mentor for each new champion. You've invested heavily in landing this person as a champion, so you must take good care of them to ensure they want to continue with the program for years to come. Have a quarterly or yearly cadence of reaching back out to the champion's manager to relay their success. If the manager loses track of their champion, you'll lose the champion in the next year, when it is time to sign up again for a follow-on year. ### Make security team marketing the norm We have seen the value of understanding and utilizing marketing techniques in our security careers. If more security people embrace these ideas, people will view security teams differently and positive change will become the norm. --- ### Why cybersecurity pros need to learn how to code - URL: https://kerrsecure.com/2022/08/28/why-cybersecurity-pros-need-to-learn-how-to-code/ - Published: 2022-08-28 - Subject: Developers & Security Culture - Author: Chris Romeo There is an age-old debate in security: Should cybersecurity professionals know how to code? Should they invest the time and effort to learn? The answer from cybersecurity professionals has usually been a resounding no. Their argument is that cybersecurity covers so much ground that it doesn’t make sense to expect every role across the security team to have coding skills. It's time to change that outlook. Having coding skills leads security people to a deeper understanding of their systems and applications—the value of computer science blossoming in front of their eyes. When you understand code, you get closer to the operation of the computer itself. > Remember, the cloud is just someone else’s computer. When you know how something works from the inside out, you open a new level of capabilities for applying your security knowledge. There are different levels of proficiency when it comes to coding. As a security professional, you don’t have to be able to commit code at the same rate as your development teams. In fact, you don't really have to do any coding on a regular basis. Just learning the fundamentals of a single object-oriented language gives you the ability to read code in many other languages. The object-orientation part is essential because most modern languages are based on this approach. Gaining an aptitude for reading code will carry you through what you need to accomplish most of the time. To help you decide whether you should learn how to code, here's a look at how coding skills enhance five different cybersecurity roles. ### Application/software security lead This one seems like a no-brainer. These security team members work day in and day out with developers, judging the activities they perform and offering advice. Any app sec lead who lacks basic coding skills and knowledge is going to be out of their depth when working with developers. There's no faking it; developers are good at discerning whether the security person they are working with has the coding knowledge and experience to offer a valuable opinion. _**Coding value proposition:** Learn to code to directly influence the developers you work with every day._ ### SOC analyst/threat hunter Analysts and threat hunters spend their days watching incident data via a SIEM, hunting for the next anomaly in the data stream, and reacting and escalating appropriately. The keyword for them is “data.” They are always looking for ways to analyze the data better, and many times that is best accomplished by writing a script in Python. Python is an object-oriented coding language and lays the foundational knowledge to understand most other languages. _**Coding value proposition:** Learn to code to write better scripts, which will help you find adversaries across all your datasets._ ### Auditor The auditor role may be the most difficult to justify. Auditors spend their time assessing requirements and creating and executing audits based on organizational policies and governmental regulations. They inspect and assess large swatches of technology and interview many technical people. Some auditors even perform testing. But any auditor would like to be able to tell whether people were withholding a portion of the truth. Enter coding skills. When auditors have a deeper understanding of computer science and programming, they ask better questions in interviews and better evaluate subjects’ answers. _**Coding value proposition:** Learn to code to unlock a superpower to help you ask and interpret better questions and answers about the things you assess._ ### Penetration tester Pen testers try to break things that others have created. But, of course, what they are trying to break is written in some form of programming language. For pen testers, the benefits of coding knowledge are twofold. First, when trying to break something, you need to understand the intricate details of how it works, and you may have access to the source code to hunt for a vulnerability in the code before writing an exploit. Second, as a tester, you write your tools to achieve results. _**Coding value proposition:** Learn to code to level up your breaking skills; it is easier to find issues when you understand the underlying construction of the things you break._ ### CISO One thing that chief information security officers have to deal with is the people who come in and out of their office all day long, either asking for money to buy new tech or explaining failures and what must change to avoid them in the future. CISOs with some knowledge of code make better and more informed decisions. They can also better determine whether they are being told the entire story as they consider the best security path forward. _**Coding value proposition:** Learn to code to enable better decision making._ ### Ideas for how a security pro learns how to code Perhaps you’re now convinced, and you’re ready to take steps to support your constituents by learning how to code. There are a few different suggestions for how you can learn and flourish as a coder. #### Online coding education Codecademy is an online interactive platform that offers free coding classes in various programming languages, including Python, Java, Go, JavaScript, Ruby, SQL, C++, C#, Swift, and Sass, and markup languages HTML and CSS. The site also offers a paid pro option that gives users access to personalized learning plans, quizzes, and realistic projects. #### Back to school For those that are more daring, your local or online university has a plethora of courses in programming. You will receive a deeper computer science understanding by going this route, but it will be more intensive. You could audit the class, but then you lose the accountability for doing the homework. #### Pairing with an existing developer As it turns out, you have a captive audience of instructors within your organization. Pairing with an existing developer is where you, as the security person, shadow the developer for a period and learn from watching over their shoulders and asking lots of questions. ### Not if, but when Security teams, you must learn how to code. Code is the language of the future and of technologies past, and to best serve your constituents, you must write code, and understand the code written by those that you support. --- ### DevOps security culture: 12 fails your team can learn from - URL: https://kerrsecure.com/2022/08/28/devops-security-culture-12-fails-your-team-can-learn-from/ - Published: 2022-08-28 - Subject: Developers & Security Culture - Author: Chris Romeo Will DevOps and DevSecOps still be relevant in 50 years? Today's DevOps technology will be long gone, but some cultural pieces may still be around. My best guess on the part of DevOps that will still exist is DevOps security culture. What is DevOps security culture?  - **Knowledge,** because there are things that you must learn and understand to build secure software fast. - **Experience,** because you improve the process and tools the more times that you fail. - **Art and creativity,** because the innovation of process and tools requires exploring new security ideas, not just relying on the status quo. - **Science,** because what matters gets measured, and DevOps security improves by measuring input and output and making adjustments. DevOps security culture is defined by what happens with security when people are left to make their own decisions. We all do the right thing for security when a security team member is standing over our shoulder. But your true security culture is revealed on Friday at 4:30 p.m. when a feature promised to a customer must either get pushed to production or shelved until next week. If there is a security issue, and the customer requirement trumps the potential platform weakness, you have a weak security culture. If a developer can say, "Nope, this has a security issue, and we are unable to push to production," you have a strong security culture. You want your DevOps security culture to continue to grow because it is crucial to your success in building secure software fast. Your DevOps security culture is a living, breathing thing. Security culture can stagnate, but it can also continue to grow if you can absorb others' learnings and failures. Here are 12 DevOps security culture fails—and how to change them. ### 1\. Name and brand The industry created a monster when it agreed to accept the term _DevSecOps_. The debate over the name—DevSecOps, SecDevOps, SecOps with dev, dev with a side of sec—has been a distraction, time misspent worrying about what amounts to a marketing term.  > Let's just call it DevOps and teach everyone that there is no DevOps without security integrated. #### How to change the culture - Embrace and believe that security is not an afterthought with DevOps. Stop using any term other than _DevOps_. - Teach all product and application-adjacent people this new definition. Your teams look to you for guidance. Standardize, and reap the reward of less confusion. - Create a "DevSecOps" swear jar, and make people add money to it every time they use the term. ### 2\. The infinity graph The infinity graph is the never-ending visualization of DevOps that shows you'll never complete anything. That is perhaps an exaggeration, but it's not a good representation of building modern software in a development organization. To make matters worse, folks will wrap a rectangle around the infinity graph and write "security" on it to represent how they integrate security into their software. > There is much more to integrating security than a rectangle. #### How to change the culture - Ban the infinity graph from your world. Choose an image or illustration that matches up to what you do with DevOps. - Embrace pipeline visualization. DevOps with security is always a pipeline because a pipeline is a factual representation of how we build software with security integrated. ### 3\. Security as a special team and lack of collaboration "Special team" is sometimes used to describe the security team. This is especially true in older companies transitioning from other software development methodologies toward DevOps, where a security team was a separate entity, but it can also occur in startups if they're not careful. Security as a particular team is a failure because when security is "special" and separate, it spends its time governing the DevOps process and the build pipelines instead of collaborating with the developers and operations folks to improve flow and security in tandem. Another failure with security teams is having team members who do not know how to code. Successful application security people can read code in an object-oriented language. To gain this level of competence, app sec people must learn at least one language. Once you discover one, you can apply that knowledge to other languages and become a trusted adviser to development and operations. Collaboration among development, operations, and security is challenging when the security team thinks it's unique. > Siloed organizations and lack of communication result in more bugs and slower building software cycles. #### How to change the culture - Security isn't special; lean into the fact that developers want to be responsible for security. - Responsibility requires knowledge and experience. - Teach everyone the foundational lessons of security. - Teach security folk how to code. They must speak the language of the developer. - To foster collaboration, institute communication paths among specialties and share both the good and the bad; no hiding anything. - Build DevOps strike teams—dev, sec, and ops together. - Foster a mutual partnership aimed at serving each other. ### 4\. Vendor-defined DevOps Who defines the DevOps standard? Where is the governing body that determines what DevOps is? Here's the catch: There is no DevOps standard. Vendors define what DevOps means in the context of their product offerings. The things that vendors want to sell represent the category. There must be a vendor-independent architecture for what DevOps means to customers. > Build the best possible solutions from your architecture, not from a vendor's playbook. #### How to change the culture - Realize that there is no DevOps standard. - Define _your_ DevOps, and do not allow vendors to define DevOps for you within the context of whatever solution they provide. - Study and teach the bigger, contextual reality of vendor-independent DevOps throughout your organization. ### 5\. Marketing term infatuation Marketing terms are a necessary evil, and they're not something that can be wished away, no matter how hard you try. "Shift left" and "shift right" are the two marketing terms that are driving the DevOps space. Shift left means you start at the beginning of your process and consider security at each step of the way. Shift right means you adapt security tools and technologies in your production environment to bolster your capabilities. Neither is wrong, but better advice is to start left and start right. The catch here is that when you start left and start right, you're back to what's been called the "secure development lifecycle" for the past 20 years. When the organizational strategy is driven according to marketing terms, you set yourself up for failure. > Follow the best practices, but leave the marketing terms to the marketeers. #### How to change the culture - "Start left" by embedding security into every section of your DevOps pipeline. - "Start right" by integrating runtime application self-protection (RASP) into production. - Meet in the middle and call what you do secure development lifecycle. ### 6\. Big-company envy Everyone wants to emulate the best. The acronym FAANG (Facebook, Amazon, Apple, Netflix, and Google) exists because small and large teams look to these giants as setters of the standard. The failure here is trying to base your DevOps security program on what the FAANGs are doing. The catch is that you're not them. You're a different organization with a different culture. > Leave big-company envy for other people. #### How to change the culture - Avoid distracting yourself by fixating on what those at the top of the industry are doing with security. - Make incremental progress: a tool here, a tool there. - Cast a vision for where your DevOps with security needs to go. ### 7\. Overcomplicated pipelines and doing everything now DevOps and pipelines are complicated beasts. If you're not careful, you can create pipelines that are so complicated, that nobody really knows how your software gets built. A lack of understanding is a tough thing to admit, and the other danger is that if you are teetering on the edge of the cliff, you're not going to be willing to accept it. The other challenge is doing everything now. As you build and mature your pipelines, the temptation exists to deploy all the tools and all the tech immediately. > Immediacy sets you up for failure because adding all these moving pieces and building complexity means it's even more challenging to understand the big picture. #### How to change the culture - Realize that there are dozens of categories of security tools. - Start with a small subset of security tools and grow the pipeline over time. Software composition analysis (SCA) and static application security testing (SAST) are the best places to start. - Keep it simple; the pipeline must be simple enough for all product and application-adjacent people to visualize and explain it. - Avoid the pressure to solve all problems immediately. Take a phased approach. ### 8\. Security as a gatekeeper The process of gatekeeping is adding manual checkpoints to an automated process, and it's a dangerous temptation for old-school security people. Security people that have been doing security for more than a decade are used to a gatekeeping approach. When things moved slowly, it was easy to make the security checkpoints exist at the main gates in a process. > DevOps goes fast and deploys often. If you're gatekeeping, there is no way things are going fast. #### How to change the culture - Practice empathy. Walk a mile in each other's shoes to truly understand the challenges of each role. - Move security toward development, development toward operations. and operations toward security. - Work together to find solutions, not roadblocks. - Provide coaches from each discipline. Coaching is a teaching method, and collaboration occurs when all the roles learn from one another. ### 9\. Noisy security tools Noisy security tools hamper the productivity of developers. A loud security tool runs in the build pipeline and then sends a 10,000-line report or generates 1,000 tickets requiring resolution. > The over-generation of data results in developers hating the pipeline security tools or, even worse, ignoring the output of the tools wholeheartedly. #### How to change the culture - Tune the existing security tools that exist in the pipeline before adding any new tools. - Never waste anyone's time with security findings that do not matter. Your team members measure the value of every tool you employ, and if you send them garbage results, they conclude that the tool is garbage. - When adding new tools, start with a minimal policy; this is one where you tune the tool to look for one specific type of error. With a new tool, most people fall into the trap of turning on a maximum policy or everything that the tool supports, and they get 10,000 results when they run the tool, a quantity that no developer could ever take action on. By setting the policy at a minimal level, the developer learns to trust the tool, and over time you can increase the number of things the tool is checking for. ### 10\. Lack of threat modeling Threat modeling is analyzing representations of a system to highlight concerns about security and privacy characteristics. Threat modeling teaches everyone in your DevOps process how to think through and mitigate every new feature's security challenges. The failure here is not tapping into the cultural eye-opening and knowledge building that security threat modeling unlocks. When all team members grasp threat modeling concepts, they start to see potential security issues and can mitigate them and make them go away early in the process. > Threat modeling makes for more secure features, applications, and products. #### How to change the culture - Perform threat modeling outside the scope of the pipeline. Threat modeling is not a pipeline activity, because it's more process than it is an automated tool. Address it correctly to maximize success. - Connect threat modeling to your approach for doling out new feature assignments. Make threat modeling inherent in your process, and threat model all things. - Teach everyone how to threat model and include the [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/) as a reference. ### 11\. Vulnerable code that's in the wild Open-source and third-party software is both great and terrible, at the same time. It's great because it provides functionality and saves us from having to create the same feature functionality over and over again. It's terrible because of vulnerabilities in the software supply chain. Vulnerable code could be a library or package with a known flaw, or a package with a backdoor. > The failure from a DevOps perspective is allowing vulnerable code to slip into the wild. #### How to change the culture - Embed SCA into _all_ your pipelines. In addition to commercial packages, open-source options are available, including [bundle-audit for Ruby](https://github.com/rubysec/bundler-audit), [Npm audit for Node.js](https://docs.npmjs.com/auditing-package-dependencies-for-security-vulnerabilities), and [the OWASP Dependency Check](https://owasp.org/www-project-dependency-check/), with numerous plugins. - Set your SCA policy to fail and break the build when a vulnerability is detected. - Ensure you have a time-boxed filtering policy. Sometimes there is no fix for a known problem yet, but you have to move forward. Instead of having a policy that allows filtering out vulnerabilities forever, time-box it so that after seven, 14, or 30 days, the issue starts to break the build again, causing developers to check if the fix is now available. ### 12\. Lack of security retrospective The final failure is forgetting to step back and examine how well security has worked out for your team. Security retrospective is about having a defined time to collect data about what went well and poorly, in a safe and blame-free place. > Failing to perform retrospective creates a culture where learning from your failures is impossible because you never stop long enough to determine how you're doing. #### How to change the culture - Always practice security retrospectives and consider security failures as you would any other failure. - Leave the blame at the door; growth comes from the ability to discuss failures freely. - Measure output from retrospectives and manage process and pipeline change. ### Go all in on resilient code Some of the above failures discussed are outside of your control, but you can change how you present and use them for your teams. Naming, infinity graphs, and marketing terms are things you can fix to create an image for DevOps-plus-security that will stick with everyone. Remember that security and coding are for everyone. You must define _your_ DevOps, not the DevOps that your vendors want you to live. Keep up the collaboration, keep it simple, lower the noise, add the best practices, threat model, add software composition analysis, and do blameless retrospectives. > You must define _your_ DevOps, not the DevOps that your vendors want you to live. Embrace and laugh at your failures. Life's too short to let your failures define you. Failure determines how you get to success. The only impact DevOps could have 50 years from now is on security culture. DevOps security culture is a work in process, so continue to create it. Continue to strive to meld together dev, sec, and ops in a shared mission to secure everything you build. It's a worthy cause and a mission with multiple levels of rewards. --- ### How to put the Threat Modeling Manifesto into action - URL: https://kerrsecure.com/2022/08/28/how-to-put-the-threat-modeling-manifesto-into-action/ - Published: 2022-08-28 - Subject: Threat Modeling - Author: Chris Romeo If you have not yet seen the [Threat Modeling Manifesto](https://www.threatmodelingmanifesto.org/), then you’re missing out. The manifesto project resulted from the gathering of 15 passionate threat modeling people, with whom I was honored to work, throwing all of their collective knowledge, wisdom, and experience into a blender. We then negotiated for six months to define the values, principles, patterns, and anti-patterns for threat modeling. The result: A document that you can use to build your threat modeling program, taking the wisdom and battle-tested experience from the authors and applying it to your organization. The Manifesto defines threat modeling as analyzing representations of a system to highlight security and privacy characteristics. Threat modeling is that, and much more. Threat modeling educates developers and testers about security from a different perspective than the OWASP Top 10 or an attacker-centric view. Threat modeling is about securing design, finding security and privacy issues, and mitigating them before they can manifest themselves in production. Threat modeling provides a path to understanding both the security and privacy challenges of a feature, application, or product, using a repeatable and valuable process for stakeholders. We did not create this document to sit on a shelf, garner academic praise, or win world awards. We made it to help practitioners build threat modeling programs. Here's how to put the Threat Modeling Manifesto into action on your dev or test team. ### 1\. Study it yourself and absorb the wisdom If you’re going to put the Threat Modeling Manifesto into action, you’ll need to understand and absorb the content found within. We wrote the document so that it has something for everyone, regardless of their knowledge level with threat modeling. If you’re a threat modeling pro with years of experience, read and review the Manifesto. You’ll agree with some parts and disagree with others. As authors, we didn’t all agree on everything, and that’s okay. The Manifesto has something for everyone, even if you don’t agree with every line. If you’re someone new to threat modeling, read through the Manifesto twice, then look at other sources to understand the different methods available to perform threat modeling. To launch your program, you’ll need the wisdom of the Manifesto and also a specific methodology. As the Manifesto says, “The Manifesto contains ideas, but is not a how-to, and is methodology-agnostic.” We wrote the document to be compatible with any method, but you’ll have to choose the methodology you’ll carry forward with your program. Study STRIDE, [LINDDUN](https://www.linddun.org/), data flow diagrams, threat trees, and tools such as OWASP Threat Dragon, and read books such as [_Threat Modeling: A Practical Guide for Development Teams_](https://www.amazon.com/Threat-Modeling-Identification-Avoidance-Secure/dp/1492056553) and [_Threat Modeling: Designing for Security_](https://www.amazon.com/Threat-Modeling-Designing-Adam-Shostack/dp/1118809998/ref=sr_1_2?dchild=1&keywords=Threat+Modeling%3A+Designing+for+Security&qid=1613166231&s=books&sr=1-2). Consider all the different, practical ways to perform threat modeling, and decide which methodology you’ll use. After you have a methodology, it’s back to the Manifesto to take the component pieces and mold them together into a threat modeling program. ### 2\. Build a threat modeling program of your own from the Manifesto’s values and principles Here is a rundown of the Threat Modeling Manifesto's values. #### **A culture of finding and fixing design issues over checkbox compliance** Culture is a crucial word in a threat modeling program. With threat modeling, the ultimate goal is to reach a point in the future where developers and testers perform threat modeling inherently with every new feature. In that future nirvana, the need for a threat modeling process dissipates. That only happens with a strong culture of finding and fixing design issues. As with all the values in the Manifesto, the first thing is better than the second thing. Checkbox compliance works for some places, and it provides some weight, but our guidance is to focus on a program that impacts your overall development culture and puts threat modeling at the front and center. _**Program building tip:**_ Focus your program on finding and fixing design issues, and make that the key metric you use from day one. #### **People and collaboration over processes, methodologies, and tools** Process, methodology, and tools are essential, but for truly secure design improvement, the key is focusing on the people and the methods they use to collaborate. Even if you have the best process, the most robust methodology, and the best tools money can buy (or open source can provide), if you don’t have people with knowledge and need for threat modeling and a culture of collaborating to squash security and privacy issues, you have almost nothing. _**Program building tip:**_ Invest in teaching developers and testers about threat modeling and set up your program to value people's knowledge and experience. Provide the collaboration best practices for successful threat modeling. #### **A journey of understanding over a security or privacy snapshot** Security is a journey, not a destination. The same holds for threat modeling. Developers and testers should think of threat modeling as a journey of learning more about their features or application's security and privacy properties each time they perform a threat model. Nobody, not even those of us that wrote the Manifesto, have all the threat modeling answers. Everyone that threat models is on this journey to expose new threats and mitigate them. We are all on this shared journey of understanding. _**Program building tip:**_ Embrace the journey. Expect threat models that have holes and encourage your threat modelers to get better with each iteration. #### Doing threat modeling over talking about it As with any topic, it is easy to spend more time talking about it than doing the activity. I have a rule when I teach threat modeling in workshops that I call the “30-minute rule.” I’m only allowed to talk about threat modeling for 30 minutes before students have to start doing threat modeling. Threat modeling is something that is better caught than taught. Threat modeling expertise sprouts from experience. The more threat modeling you perform, the better you get at it. _**Program building tip:**_ Focus your developers and testers on performing threat modeling quickly. Follow the 30-minute threat modeling rule. #### Continuous refinement over a single delivery The threat modeling journey demands constant reinvestigation. Over even short periods, features change; applications gain new features; software is continuously evolving. Threat modeling is something that you must revisit at a constant time interval. Threat modeling is never complete; you always need to rinse and repeat. _**Program building tip:**_ Ensure the revision of threat models according to a defined time; do not allow threat models to die on the vine. #### Teach it to your developers and testers You’ve studied and decided upon a methodology. You’ve built a program on top of the Threat Modeling Manifesto’s values. Now it’s time to teach threat modeling and the goodness the Manifesto contains to all of your developers and testers. You could choose to teach them using the workshop model, where you gather a group together for a two-hour session, with 30 minutes of instruction and 90 minutes of threat modeling exercises. Whatever method you choose, take the message to those who need to threat model and encourage them to teach others. Threat modeling is a discipline that magnifies as more people buy in. Once you buy in, you’re inclined to introduce more people because of the value you see in the mitigations that come from the process. ### Teach the developers and testers well Study the Manifesto and take away the lessons that apply to your program. Review the methodologies and choose the best one for your organization. Build a program upon the Threat Modeling Manifesto’s values. Teach your developers and testers to threat model according to the plan you’ve laid out. With every person you empower to threat model, a feature or product's security and privacy get a tiny bit better. Take threat modeling to as many people as you can[,](https://web.archive.org/web/20230909075907/https://techbeacon.com/security/5-ways-scale-your-app-sec-program) and you just might change the world, one small step at a time. --- ### The state of DevSecOps: 5 best practices from the front lines - URL: https://kerrsecure.com/2022/08/28/the-state-of-devsecops-5-best-practices-from-the-front-lines/ - Published: 2022-08-28 - Subject: AppSec Programs & Practice - Author: Chris Romeo Ladies and gentlemen, citizens of the Internet, could this be the year when DevSecOps finally catches on everywhere?  DevOps is continuing to cause culture shifts far and wide, as old-school enterprises attempt to shift their software development, test automation, and delivery approaches and adopt a DevOps mindset. There is a maturity divide between the haves and have-nots of DevOps, and this has an impact on security. The story is the same; we've been telling it for years about agile, to the point where it's become a joke: Ask two companies what agile is, and you get three different answers. The same applies to DevOps. We all know the guiding principles of DevOps, but organizations are picking and choosing from those principles and still calling it DevOps. The non-negotiable nature of secure DevOps, or DevSecOps, states that "the DevOps culture embeds security within."  The trend in 2019 continues down the path of evangelizing "shift left," "build security in," and "just do security in DevOps." The best place to do security in DevOps is sprinkled across the entire pipeline. There certainly are plenty of vendors creating solutions focused on securing the build pipeline and operating at speed and scale. This is a good evolution for our industry and provides more tools to perform the automated tasks that we need.  Other trends affecting DevSecOps include containerization, microservices, and serverless.  More people are talking than acting on DevSecOps, and that is because the struggle is real. There is an industry immaturity in the DevOps approach that affects most companies. Case studies always focus on the high-flying, top-of-industry DevOps champions. Sure, the Netflixes and Etsys of the world operate securely at speed and scale, but they are not average DevOps consumers. Security is hard enough to build in when things work in yearly cycles. Now that we have to take tools that used to take eight hours to run and try to get them down to seconds, this just adds to the struggle. Software supply chain and third-party software management of vulnerabilities continue to wreak havoc across modern applications. Despite the current state of DevSecOps there is hope. Best practices are emerging. Here are the most successful ones to consider this year. ### 1\. Put your talk into action Make a plan for real action about how to integrate security into your DevOps pipeline. Honestly assess where you are today and where you want to go in the future. Build an achievable plan and then start to implement it.  ### 2\. Deploy open-source governance Open-source governance is more than just a tool. Yes, some tools provide this capability; these tools are quite good at tracking usage and vulnerabilities. But more than tools, deploy the open-source governance process that adds real consequences for the use of vulnerable open-source software.  It's 2019; we all know this is a problem. Moreover, of all the challenges we have to deal with, this is not that hard. There are plenty of commercial providers of software composition analysis tools, but also check out [OWASP's Dependency-Track project](https://dependencytrack.org/). ### 3\. Automate all security things, including threat modeling The most mature DevSecOps programs are executing a full suite of application security automation. These automated tools include static application security testing, dynamic application security testing, software composition analysis, and interactive application security testing. The security vendors have great solutions here, so push them to provide you with products that are truly automated. And create a culture where security tools make developers' lives more comfortable and not more difficult. Do not ignore the forgotten manual tool right in front of you: threat modeling. Different levels of threat modeling occur in a DevOps context. You can achieve threat modeling as code through the use of new approaches. You'll still need to consider threat modeling at the higher-level architecture layer, but threat modeling as code increases your automation levels significantly. ### 4\. Implement container security Container security includes many issues for consideration. Containers can contain open source, and that software can contain vulnerabilities. Non-approved images provide features and functionality that do not meet your organization's vision (crypto-mining, anyone?). Secrets management is notoriously tough and is all too often done using GitHub and a YAML file. Develop your container security solution, and piece together open-source and commercial solutions to address these issues. Containers provide a massive advantage to security, with isolation and dependency conflicts things of the past. But you must take steps to address open-source vulnerabilities, use of non-approved images, and secrets management. ### 5\. Design consistent security for microservices, APIs, and serverless Design and deploy consistent security for all unique approaches to application delivery. Integrate all of your services into your secure DevOps pipeline. While microservices, APIs, and serverless sit above the pipeline, they are the areas that require the most consistent security focus for 2019 and beyond. These areas suffer from a lack of consistent security implementation. Take a look at your consistency across these areas; you might be surprised to find that your security approach is different for each category. ### Don't hold your breath DevSecOps has not arrived with the rush of the new year. DevSecOps is still immature—not in methodology, but in implementation. This is the year we need to take more action and talk less. Solve the open-source problem once and for all with a governance structure that mitigates software deployment with vulnerabilities. Truly automate all the security things, including the containers. Educate your teams to apply security consistently, across all the unique approaches to application delivery. The code you save might be your own. --- ### How to do application security on a budget - URL: https://kerrsecure.com/2022/08/28/how-to-do-application-security-on-a-budget/ - Published: 2022-08-28 - Subject: AppSec Programs & Practice - Author: Chris Romeo As a bit of a thought experiment, I asked myself, “What if I had to develop an application security program with a budget of zero dollars? How would I do it?” People often talk about unlimited security budgets. Some of the largest companies in the world have gone on record to say that there is no limit to what they'll spend on cybersecurity. Looking across the industry, this is not the norm for most organizations. But you _can_ create an application security program on a zero or limited budget. Traditional application security programs include people, processes, and tools. The people include your security champions or advocates who are passionate about security. Your constituents or consumers of the program include developers, testers, program managers, product managers, people managers, and executives. The process consists of your secure development lifecycle, product security incident response (PSIRT), and bug bounty efforts. Tools provide automation of security tests and include all the four-letter acronyms (SAST, DAST, IAST, RASP), and even a three-letter abbreviation (SCA). All of these pieces have one thing in common: They generally cost money to purchase or support. > OWASP is the hidden gem of the security world. The key to application security on a budget is tapping into the OWASP universe. OWASP is the Open Web Application Security Project, a not-for-profit working group of the finest minds in application and software security. Volunteers create open-source security projects, gather a team to collaborate, and crank out the best guidance and tools on the planet. Just because they’re free doesn’t mean these projects don’t pack a massive amount of value. OWASP is the hidden gem of the security world. Here's how to put the OWASP project to work for your organization, no matter how big or small your budget. ### Level set and go Regardless of how much money you have in your budget, you likely have a set of goals in common with everyone else in the industry. First, you want to limit vulnerabilities in deployed code. Secondary program goals include building secure software and teaching developers to develop secure software, providing processes and tools for application security standardization, and demonstrating software security maturity through metrics and assessment. Most people have sizable budgets and can purchase whatever they need (to a degree) to ensure program success. You can use OWASP to enhance your program in certain areas using the resources available. If you have a small budget or no budget, use OWASP to fill in the missing spaces on your plan. One word of caution before you jump headfirst into the OWASP pool: OWASP projects come and go. Some release, never to be heard from again. There is no guarantee that a project will ever reach a formal release or have a second version created. Use OWASP projects at your own risk. Spoiler alert: I think they are worth the risk. ### Awareness, knowledge, and education programs The first group of OWASP projects is categorized as awareness, knowledge, and education. These projects focus on preparing the people in your organization to understand and apply the ways of application security. #### Top Ten The Top Ten is the original and seminal work within the OWASP universe, listing the top 10 web application security risks. This document can guide your entire team in understanding the most significant threats to your organization regarding web applications. The first version of the Top Ten was released in 2003, and it has undergone many revisions over the years. The 2017 edition includes injection, broken authentication, sensitive data XML external entities (XXE), broken access control, security misconfiguration, cross-site scripting (XSS), insecure deserialization, using components with known vulnerabilities, and insufficient logging and monitoring. The value of the Top Ten comes from the fact that risks are sorted using industry data, and high-level mitigations to fix these issues are presented. The Top Ten provides a foundational understanding of the most essential concepts in app sec. Teach it to everyone in your organization. #### Proactive Controls The Proactive Controls are written for developers, by developers, and it includes what your developers need to do to build better products. This is the concise guidance your developers need to counter each and every one of the Top Ten. The current OWASP Proactive Controls are "Define Security Requirements," "Leverage Security Frameworks and Libraries," "Secure Database Access," "Encode and Escape Data," "Validate All Inputs," "Implement Digital Identity," "Enforce Access Control," "Protect Data Everywhere," "Implement Security Logging and Monitoring," and "Handle All Errors and Exceptions." The value of the Proactive Controls comes from their concise nature (two to three pages per issue). While everyone in an engineering organization should understand the Top Ten, Proactive Controls are foundational knowledge for everyone who touches code. #### Juice Shop Juice Shop is a vulnerable web application written specifically to contain the issues found in the Top Ten. Juice Shop provides developers with hands-on experience exploiting web application security issues. You can explain a problem to developers, but until they have laid their hands on the keyboard and exploited said issue, they have not truly understood it. Juice Shop's value is derived from the assimilation of crucial concepts through activities that lock in knowledge and make it practical. #### Cheat Sheets Cheat Sheets provide a knowledge base for how to do things securely. Over the years, various OWASP volunteers have noted that there are issues that come up often in most web applications. These volunteers create a cheat sheet to describe the problem and offer a solution. As an example, there is a password storage cheat sheet. Storing passwords is often done poorly, leaving one of our most sensitive pieces of data vulnerable. The password storage cheat sheet describes issues to consider and also recommends solutions using various encryption algorithms and employing password hashes securely. The Cheat Sheets provide a concise reference for solving the most challenging application security problems. Point your developers to this resource to help them avoid trying to answer the hard questions that already have decent and secure solutions. ### Process and measurement projects The second group of OWASP projects involves process and measurement. Process and measurement help you to define, govern, and measure your program. #### Owasp SAMM SAMM is the Security Assurance Maturity Model, and it provides a catalog and assessment methodology for measuring and building an application security program. SAMM provides high-level categories of governance, construction, verification, and operations. Each of these top-level categories has a series of subcategories. For example, governance includes strategy and metrics, policy and compliance, and education and guidance. Each subcategory contains guidance on how to build out a portion of your program. As an assessment methodology, SAMM provides spreadsheets with questions for use in an assessment of your organization. The SAMM spreadsheet tools index and compile results, with charts and graphs you can share with your executive team. SAMM provides a roadmap of where you are today and helps you build a plan for where you want to go with your program in the future. #### ASVS ASVS is the Application Security Verification Standard. It is a collection of application security requirements, written in such a way as to be verifiable. ASVS defines four levels—cursory, opportunistic, standard, and advanced—and prescribes different depths of requirements based on your assessment of the criticality of a given application. ASVS serves as a base set of requirements that you can build upon. Why create your own set of requirements for web application security when such a robust framework exists for your use? If you must produce something of your own, use the ASVS as a baseline to build upon. #### Application threat modeling OWASP's advice on application threat modeling includes examples. Application security people all agree on the importance of threat modeling. This project provides a simplified approach to getting started. The basis of this methodology is asking four questions: What are we building? What can go wrong? What are we going to do about that? Did we do a good enough job? Threat modeling is difficult at first. The OWASP application threat modeling project acts as a reference methodology for how you can teach all your developers to threat model. #### Code Review Guide The best security-focused code review begins with a secure code review checklist. The Code Review Guide provides you that checklist and also describes all the other things you must understand about code review for web applications, with example snippets of code and guidance on what to look for. Code review is hard enough without a baseline checklist. Use the Code Review Guide to help your developers know what to look for. #### Testing Guide Developers tend to lack knowledge of how to perform application-focused security testing. The Testing Guide explains how to test and provides a knowledge base on how to exploit web application vulnerabilities. The Testing Guide is an in-depth resource with examples that walk your developers through how various Top Ten issues play out. The Testing Guide serves as a guide and a resource for when your developers need to understand a vulnerability type in more depth, and also for when they need to know how to test for a particular vulnerability class. ### Tools The third and final set of OWASP projects is tools. Tools provide automated methods to extend your program’s capabilities with a small investment in time. #### Core rule set ModSecurity is a plugin for the Apache web server that allows it to act as a web application firewall. ModSecurity is managed and built from outside of OWASP, but the Core Rule Set is an OWASP project that defines the intelligence via rules that truly block web application threats at the web server layer. The value of the Core Rule Set is that it provides a web application firewall solution for free. And if for some chance you are questioning how useful this technology is, you should know that it is used in many of the commercial WAF solutions from service providers. #### Dependency Check Dependency Check identifies vulnerable third-party software in your build pipeline. Third-party software is riddled with vulnerabilities, and Dependency Check provides an automated method to detect vulnerable software and break your build until the vulnerable software is eradicated. There are many commercial offerings in the software composition analysis space, but pound for pound, my money is on Dependency Check and its sister project, Dependency Track, which adds enterprise-level management across your entire application fleet. #### ZAP Last but certainly not least is the Zed Attack Proxy or ZAP. ZAP provides two primary functionalities, acting as a web proxy for manual web application security testing, and automating scanning capability, providing a DAST-like service. The value of ZAP comes from placing it on developers’ desktops to enable them to perform manual app testing, and also from using it as a component of your build pipeline, as a simple scanning tool for running your web applications. ### Bang for your security bucks—no matter how many you have Doing application security on a budget is feasible, and in my mind, the wisest way you can approach your program, even if you have a budget with many zeroes on the end of it. As you plan the rollout or augmentation of your program, remember to use SAMM to assess your current program and future goals. Start small by choosing one item for awareness and education to launch your program. Evaluate the available projects in each category and build a one-to-two-year plan to roll each project out. While OWASP is free, the headcount is not; plan for the headcount to support your "free" program. OWASP has a robust chapter program, so connect with fellow OWASP enthusiasts in your locale, and join the movement by starting a new project or collaborating on an existing one. It takes an industry to work together to enable application security on a budget. --- ### How to hack your security culture - URL: https://kerrsecure.com/2022/08/28/how-to-hack-your-security-culture/ - Published: 2022-08-28 - Subject: Developers & Security Culture - Author: Chris Romeo Changing security culture appears straightforward at first glance: You tell people to do things differently than before, and then stand back and wait for lower vulnerability counts and improved code. But it's more complicated than that. How do we measure security culture? Easy. Its strength will be clear if, one Friday at 4:30 pm, a developer finds a potential security vulnerability and must make a decision: stop the deployment and/or fix it, or commit the code and deal with the issue after the weekend. If the developer holds up the deployment, your security culture is strong. You can hack your security culture so that people consistently choose the path of security. Here is one proven approach. ### Start with one person at a time To hack your security culture, you apply a series of shortcuts or tricks for getting an organization to focus on security, one person at a time. A security culture hacker is a person who manipulates the organization in such a way as to improve the state of security. Security culture hackers demonstrate common characteristics that result in success. These characteristics begin with communication, active listening, and collaboration. Security culture hackers must first and foremost connect with the people they are trying to influence. Influence is achieved by understanding the challenges those people deal with and documenting those challenges accurately. Also important is in-depth knowledge of the area of security you are trying to reach (developer versus general security awareness). The culture hacker must be knowledgeable in the target area to intelligently build solutions for change. Then comes methodology and lingo. The hacker must know the terms that best communicate to the target audience. As an example, in talking to developers, the hacker must understand programming concepts and the process for software development to implement change. Finally, the hacker must have an edge and not always be the nice guy or girl. To make an omelet, you need to crack some eggs, and to change a security culture, you need to crack some existing ideas and the "we have always done it this way" mindset. The process of security culture hacking can be broken down into five areas: assess, communicate, connect, educate, and reward. ### Phase 1: Assess Assessing is all about creating a strategy based on where the organization needs to go in the quest for a healthy security culture. A strategy is established by evaluating the current state of security via interviews and surveys and then processing the results into a plan to move things in a positive direction. Culture change is a long game, and if you don't know the current culture and try to build a strategy for changing it, you've already lost. Understand where the organization is before trying to create change. Ensure that you develop a strategy as a result of your assessment. An assessment without a plan is a waste of time. Some sample questions will help in your quest to understand your current security culture. (You can also use other resources, such as the SANS Security Awareness Maturity Model and the OWASP OpenSAMM standards for assessment.) - What does security mean to us as an organization? - How do we "do security"? How does security affect each job role? - How risky is our application fleet or data that we store? - Who are the attackers we face? - Should we do high-level security-awareness training? Role-specific? - Ever heard of a secure design principle? What are some that we apply? - Do we have a security response team? How do we contact it? A solid practice for assessment is to use the water-cooler principle. After meeting with executives about the state of security, say you're going to get a drink of water. Head to the break room, and then wait there for a few minutes. When people walk in, ask them what their job role is and what security means to them. The answers you receive may be different from what you heard from the executives. #### Tips for assessment - Time-box the assessment effort; the security culture hacker needs data for where the organization is today, but not a 100-page report. - Ensure that the assessment becomes a strategy; an evaluation by itself is just a stack of paper. - Engage the people who do the work; hear from the managers and executives, but double-check their answers with those who do the job. - Meet the organization where it is, or where it looks like it is going. ### Phase 2: Communicate Reach out to people from across the organization, at all levels, and tell them about security. There are three different approaches to security communication: bottom-up, top-down, and hybrid. Bottom-up communication focuses on making a grassroots connection. Schedule one-on-one meetings with the people who do the work, to create a relationship. In the beginning, schedule as many of these meetings as possible per quarter. Top-down communication focuses on the executive suite first, then moves down. With this approach, you ask the executives to sign off on your proposed security changes and then propagate them across their teams. Many organizations require executive management buy-in before moving forward with any change. With a hybrid approach, you meet in the middle, using both bottoms up and top down. This is the best possible solution since you work with the people who do the work and also the people who control the resources. If you find yourself in an organization where executive management is slow to act on security change, you may have to practice some scare tactics. For example, you might exploit vulnerabilities in your products or applications right in front of your executive staff. That makes security real. #### Tips for communication - Build a strategy to reach the most critical teams or groups first. Flagship products or parts of the business are great advertising for security culture. - Tap into groups that have real passion. Existing security passion equals early wins. - Analyze vulnerability counts by the team (if a metric is available). - Do not hit people up on day one to commit a percentage of their work life to security; ease into what you are asking from them. - Talk about security with anyone who will listen: the cleaning staff, the UPS person, anybody. ### Phase 3: Connect Connection is about embedding expertise within every team. A security champion program, with champions drawn from outside of the security team, allows you to reach beyond the security team and engage many resources. Security champions are also called advocates, ambassadors, and guild members. The idea is to harness those passionate about security, provide them with in-depth lessons, and then unleash them in the organization. [Adobe](https://web.archive.org/web/20200808103921/https://blogs.adobe.com/security/2016/05/building-a-team-of-digital-marketing-security-champions.html), [Cisco](https://www.cisco.com/c/dam/en_us/about/security/cspo/csdl/docs/External_CSDL_Whitepaper_Final.pdf), and [Salesforce](https://www.sans.org/security-awareness-training/blog/security-champions-program-eu-secawaresummit) have all had successful security champion programs, as shown in industry case studies. #### Tips for connection - Ensure proper organizational distribution, with champions from every functional group represented. - Define champion roles and expectations; clearly delineate what you want the champions to do and the schedule. - Obtain management support in advance. - Create a program as a destination, one that people seek out. ### Phase 4: Educate This must be done with meaningful, transformational security education that everyone wants to consume. There are various ways to conduct security education. Video and hands-on training scale for both large and small teams. Classroom and in-person training has a high return but is hard to scale to large groups. #### Tips for education - Begin with the basics; never assume base knowledge. - Start with why; focus on why the learner needs to care. - Connect your security champions with the education program. - Recognize individual achievements or levels. - Pick a fun theme and market the program using the idea. ### Phase 5: Reward This involves encouraging the adoption of a security culture with more carrots and fewer sticks. People like recognition for their work achievements. Rewards are an inexpensive way to bolster the image and return of your security culture-changing program. **Reward examples** - Saying "Good job" in front of the team - Email from a boss or executive - Gift cards - Cash - Enhanced training - External conferences As your program matures, you might be able to offer exceptional rewards for those people who have persevered within the security program as volunteers for years. An example of this might be sponsoring a master's degree in cybersecurity. This would go beyond normal tuition reimbursement, which usually requires up-front payments. Provide this enhanced top-level reward for those who have gone far beyond what they were expected to do. #### Tips for rewards - Ask team members for reward ideas. - Plug into existing organizational rewards and recognition programs. - Reward early and often; a rewards program is not a place for stinginess. ### Keep on culture hacking If you find yourself in need of security culture change, remember the phases. The approach is cyclical, so once you complete all the steps, go around again and see the continued positive impact on your team of security culture change. --- ### What I Learned in Year 5 of MY Security Journey - URL: https://kerrsecure.com/2022/08/28/what-i-learned-in-year-5-of-my-security-journey/ - Published: 2022-08-28 - Subject: The Security Journey Years - Series: The Security Journey Years, part 6 - Author: Chris Romeo _Photo by Pixabay on [Pexels.com](https://www.pexels.com/photo/boat-boating-close-up-coast-275637/)_ While the year 2020 is not one we'll soon forget, this was a year of extreme growth for Security Journey. We doubled in size, from four people to nine. (And yes, we did this without venture capital.) We moved into our first office and built our production studio. It's incredible what a team can achieve with passion and an innovative, security culture-changing product. Here are a few key growth lessons I've learned over the past year. ### **1.  A strong team creates more than its individuals.** As we've grown from four people to nine, we've seen the value in a strong team and the magnification of output. A strong squad creates so much more than a collection of individuals. I've watched our application security engineers work together to deliver JavaScript / Node.js content and a brand-new course on R Security for Data Scientists. All in a concise amount of time. Because of this, we will dramatically ramp up our content release schedule in 2021. As we welcomed a new marketing lead, sales and marketing have connected and strategized about how we're going to rock 2021. A strong team works well together and looks for opportunities to serve each other. We're building this culture. ### **2.  Choosing new team members is everyone's responsibility.** _On_ the heels of my item about a strong team is the process of choosing new team members. I've seen firsthand the power of including the existing team when selecting new team members. At my first professional security job at Arca Systems, we had a process of interviewing I had never seen before. When I interviewed for my role, I visited the offices and spent the day speaking with seven different people from various functions. Arca's idea was to have a candidate talk to enough people that they would let it slip at least once if they were not the right fit. I joked with the HR manager about if my final interview would be with the custodian to discuss my cleanliness habits. What I learned and have now applied at Security Journey is that we have a cross-sectional group of people interview a candidate (at this stage, that means everyone). During the wrap-up call, everyone can say thumbs up or thumbs down. If anyone says thumbs-down and has a valid reason, that candidate is off the table, no matter how much I as CEO think they are the best option. Strong team members build strong teams that fit the culture. ### **3.  Growth requires spending money.** You might read this and think it's common sense. As a bootstrapped company, the growth of headcount must track to increase in revenue. Over the past year, I've realized that there are times in the bootstrapped company's life when we must step out and go for it. We cannot track a specific equation for growing the team based on a fixed amount of money. Sometimes we must take chances and project what the future will hold. Then as a team, we go after it and hit our target. ### **4.  There is a time for new features and a time to focus on stability.** As our platform has grown, our need to focus on performance and user experience has increased. When your daily user count grows exponentially, you must evolve the platform to keep up. This year, I've learned that sometimes, as an engineering team, we must put the new features off to the side and focus on platform stability. Platform stability is not always the most exciting part of what we do, but it's paramount to ensure that our platform is performant in all situations. ### **5.  It is easy to do Marketing haphazardly, but a structured approach and investment drives lead generation.** As a startup, you can't have everything all together from the very beginning. For us, marketing was something that we always did, but haphazardly. I spend time speaking at various industry events, host the Application Security Podcast, and have a website and webinars, etc. Bringing in a marketing lead that is now bridging all these things together is almost priceless. I'm excited about what our marketing lead can do by taking all the content and projects we've done in the past and turning them into a coordinated marketing approach. ### **6.  Being an AppSec Practitioner is our superpower.** When I look across the security education industry, I see companies that exist because venture capital exists. Someone had an idea, pitched the idea, got an investment, and now is building a product or solution. The only thing they're missing is the experience in delivering the end result they're selling. At Security Journey, we're a practitioner-led company of people that have been there/done that. We live and breathe Application Security and how to teach it better. We've built security culture-changing programs at scale for the largest companies on earth. As we solve more and more complex security culture/education challenges for our customers, one of our superpowers is that we've done this before, at scale, and that experience is a powerful advantage. ### **7.  Add value to your customers by bringing them together.** We began a group this past year called the Security CultureCollective. This group represents the program leadership of all of our customers. We gather once a month to discuss a specific topic related to security culture. We talked about security rewards and recognition, had various members present their programs, and even talked about running successful virtual events. We're building community and value for our existing customers by bringing them together in a trustworthy environment focused on collaboration between professionals who share the same need for security culture. We're genuinely bringing this group together for their benefit. Changing security culture can be a monumental task – and assisting our customers to achieve their goals goes way beyond our training platform. (Yes, only existing Security Journey customers are allowed to participate.) ### **8.  It's better to lead than follow, and people love something natural and not contrived.** When I think about marketing efforts, I chuckle as I see every Application Security company getting into the podcast game. We've been running the [Application Security Podcast](https://appsec.buzzsprout.com) for 5+ years now. As the rest of the industry focuses on "catching up," they build podcasts concentrating on them and their agenda. Our podcast focuses on interviewing exciting people doing exciting things in AppSec. We've never made it about us, always about the learning and sharing of knowledge. I started the podcast because I wanted to meet more people in AppSec and learn from them. I'm thankful for our loyal base of fans that listen to the podcast to learn from us. Because of this, my goal for Security Journey has always been to create content designed to share knowledge and give back to our community. We do this in our platform, but also through the podcast, blogs, and speaking events. Our growing content team and I will continue this in 2021 and beyond. These are my learnings from last year. Please share this far and wide, and here's to a fun and rewarding year six! --- ### What I Learned in Year Four of MY "Security Journey"​ - URL: https://kerrsecure.com/2022/08/28/what-i-learned-in-year-four-of-my-security-journey/ - Published: 2022-08-28 - Subject: The Security Journey Years - Series: The Security Journey Years, part 5 - Author: Chris Romeo 2019 was quite a year for Security Journey, as we added additional team members, and are about to double the size of our sales staff. I've recounted a startup adage I've heard a few times from different places: with startups, you get the highest highs and the lowest lows. What nobody tells you when you start is that sometimes they happen on the same day. I'm not complaining, as one of the things that I love about the startup world is the constant problem-solving and challenges that arise. I'm a problem solver by nature, and could not imagine doing anything else at this stage of my career. **Here is my list of year four lessons learned.** 1. **Venture capital is not required to grow a company.** My statement is countercultural in the startup world. I'm not saying we will never take money, or that I'm against venture capital. I'm saying that I've realized that for us, it is possible and okay to grow more slowly, regardless of what the industry says. Revenue drives growth, and we have it. 2. **The CEO wears many hats and must look for opportunities to shed some hats as the company matures.** I mentioned last year about the swim lane analysis and how powerful that exercise is to capture the depth of all the things that I do as CEO. Shedding some hats is more difficult at our current stage, but we have been able to create a Customer Support function. We've also built a stack of our next ten hires, based on where we need the most help. I love to develop content and guide the design of our platform, and one of my goals for 2020 is to spend more time on those two things. 3. **Sometimes an opportunity is core, and other times its context.** For a bootstrapped business, you either invest your own money or work on other things to cash flow growth. It's essential to realize what is core and context for your business. We went through this exercise last year. Our growth has allowed us to focus almost exclusively on the core for 2020, but for a bootstrapped company, cutting the context is more complicated and feels much riskier, but it must happen. 4. **Having a booth at events that target our core customers is a splendid way to generate leads.** [Justin](https://www.linkedin.com/in/justinwredberg/) from our team is an excellent salesperson and has a hidden talent for design. He designed and oversaw the construction of our own custom booth, which stands out amongst all the other booths at the events we've been to. We've found that targeting specific events results in plenty of conversations and demos at the booth. We use a different strategy for more significant security events, where our audience is just a small percentage of available attendees. We built a collection of laptop stickers that are topical and humorous, and they have been well-received worldwide. 5. **Company culture is a difficult thing to quantify.** We've documented our core "culture" and values at Security Journey, and it was a more complicated process than I would have thought. It's nice that we have a few years of experience where culture was caught not taught, as we have documented what is typical for Security Journey. Still, if you had asked me four years ago about the difficulty level of recording and building company culture, I would have said "easy." The advice here is to not stress about the perfect culture document, as culture is a living and breathing thing. 6. **Giving back to others at different stages of the startup journey feels good.** I've had the opportunity to meet with other entrepreneurs with companies at various stages, and offer advice to them. I initially thought that I would not have much to offer, but I've realized that surviving for four years with a startup and still feeding my kids counts for something! 7. **Product pricing is an art and not a science.** Pricing is one of the most often written about startup topics. We've had multiple different approaches to pricing over the last year. We went innovative, and it was too hard for some to understand. We went back to a classic approach, but that doesn't have enough upside for security culture growth companies. We've landed on a hybrid that serves all our customers well, and I'm sure we'll continue to tweak it for 2020. 8. **When facing a challenging decision, build a company that I'd like to work for.** As we've grown in the past year, we've worked hard to grow up our benefits packages. As I had to contemplate how much to contribute from the company, I landed on a straightforward question: if I choose a specific amount or value, am I creating a company that I'd be excited to work for? If the answer is no, then I need to reassess my decision. 9. **Interviewing potential employees is a team effort and everyone's vote matters.** As we've interviewed folks this year, I remembered something I learned the hard way previously in my career. When hiring, everyone on the team is involved in the process, and everyone gets a say. In the past, I've hired at other companies and vetoed my team's opinion, and paid the price. At Security Journey, everyone from the direct team participates in the interview process, and everyone gets a say in whether we move forward with a candidate. 10. **Hire for competence and cultural fit, and don't discount the cultural fit.** When a company is small, you worry about hiring a person unable to fulfill the job responsibilities and not so much about the cultural fit. I've learned the importance of considering both the cultural fit and the added value a person brings to the table outside their core competencies. When you are small, everyone wears multiple hats. Work should be a place to excel, kick butt, and have fun with those around you. ### These are my learnings from last year. Please share this far and wide, and reach out if you think Security Journey could help your organization, or to catch up. Here's to a full and rewarding year five! If you want a bit of history you can read where this story began with The Day I met John Chambers... and Quit., What I Learned in Year One of MY "Security Journey, "What I Learned in Year Two of MY "Security Journey, and What I Learned in Year Three of MY "Security Journey." --- ### What I learned in Year 3 of MY "Security Journey."​ - URL: https://kerrsecure.com/2022/08/28/what-i-learned-in-year-3-of-my-security-journey/ - Published: 2022-08-28 - Subject: The Security Journey Years - Series: The Security Journey Years, part 4 - Author: Chris Romeo Startups are challenging. They push you to the edge and back. I'm proud to say that Security Journey is continuing to grow as we complete our third year, and look into our fourth. We hired our first employee a few months back, to focus on sales. We are looking for a primary Senior Security Learning Consultant to help us deliver on our content roadmap for 2019.  Our customer reach continues to grow. With each new customer we engage with, we are finding that everyone has the problem that we solve. Everyone wants their developers to focus more on security. And we have their answer. We have done some custom security awareness content generation for a client, and are looking to grow that product line in year four. **Here is my list of year three lessons learned.** 1. **A Salesperson does not equal offloading of all sales activities.** When we hired [Justin](https://www.linkedin.com/in/justinwredberg/) to lead sales for Security Journey, my thought was "Now we have someone in Sales; ahh, time for me to rest from Sales activities." I was quite surprised to discover that having a dedicated salesperson has me more focused on Sales than ever before. Justin handles executing the Sales process, but as the startup CEO, I'm heavily involved in Sales, sharing my story and the product vision. I am the most qualified person to share my story. 2. **An Executive Coach is a worthwhile investment.** My friend Andrew told me about his experiences working with an Executive Coach. As he was describing the process of working with a coach, I thought I would give it a try. My Exec Coach has been an excellent sounding board as I wrestle with various issues impacting Security Journey. A good Exec Coach is part therapist, part startup specialist, and part consigliere. I joke with him that 75% of the time the act of verbalizing what I'm dealing with causes me to figure out the answer on my own. All joking aside, my Coach has advised me well in year three. Thanks, [Bob](https://www.linkedin.com/in/bobgreisman/)! 3. **A swimlane analysis is downright shocking.** An advisor to Security Journey recommended that I go through a swim lane analysis. He challenged me to analyze all that I do, and separate each task into swim lanes or roles that I fulfill. This was downright shocking when I realized where my time was going and how little of my time was being dedicated to some things that I thought were very important. The swim lane analysis opened my eyes to the fact that we needed a salesperson, and it has also shown me the benefit we'll receive from bringing on a Senior Security Learning Consultant and a full-time developer early in year four. 4. **Pitch decks are great even if you aren't looking for money.** We went through the exercise of creating a pitch deck, and the process was worth its weight in gold. We had to consider markets, pricing, staffing, competitors, and expense profiles. The method of building a pitch deck forced us to wrestle with some issues and ideas about our company. If we decide to fundraise, we are prepared with the right documentation, and if not, the work gained us a great appreciation for where we are and where we need to go strategically. 5. **Focus on what you can control.** Help customers, chase opportunities, build an excellent product and let the competitors do their thing. I'm a very competitive person. I don't like to lose at anything. I learned this past year that there are things I can control and things I cannot. I need to focus on what I can control and let the rest take care of itself. Stressing over a new competitor does nothing to help Security Journey. We must focus on what we can control (building an excellent product that changes security culture) and let everyone else worry about them. 6. **Public speaking takes up a disproportionate amount of time.** I love public speaking and sharing my security knowledge with the world, so this one hurts a bit. In years one to three I traveled the globe, speaking in Norway, England, and across the United States (RSA, ISC2 Security Congress, OWASP AppSec USA), just to name a few. I'm going to pull back on my public speaking in year four and focus on product development. I love to attend conferences to connect with friends and fans but need to limit this time investment in year four. 7. **Where company time is invested, the company must benefit.** I created the [Application Security Podcast](https://appsec.buzzsprout.com) with Robert Hurlbut a few years ago, and from the time we started, we focused on having it non-commercial. This past year I realized that Security Journey was sponsoring the podcast by paying for hosting, production, and some travel that benefited the podcast. I made the decision (after consulting Robert and a cross-section of our audience) to add an advertisement for Security Journey into the podcast and use it as a way to promote what Security Journey does. ### This is what I learned last year. Please share this far and wide, and reach out if you think Security Journey could help your organization, or just to catch up. Here's to a full and rewarding year four! If you want a bit of history you can read where this story began with The Day I met John Chambers... and Quit., What I Learned in Year One of MY "Security Journey," and What I Learned in Year Two of MY "Security Journey." --- ### What I Learned in Year Two of MY "Security Journey" - URL: https://kerrsecure.com/2022/08/28/what-i-learned-in-year-two-of-my-security-journey/ - Published: 2022-08-28 - Subject: The Security Journey Years - Series: The Security Journey Years, part 3 - Author: Chris Romeo I'm two years into my Security Journey as Co-Founder and CEO. We've already beaten the odds by surviving our first and second birthdays, for which I am very thankful. This has been a year of new product releases, customers, connections, and lessons learned. We are still bootstrapping our product development efforts and learning on the fly. Like my first-year summary, this is a raw and wide-open view into Security Journey's second year of existence. If you want a bit of history you can read where this story began with "[The Day I met John Chambers... and Quit](https://kerrsecure.com/2022/08/28/the-day-i-met-john-chambers-and-quit/)." and "[What I Learned in Year One of MY "Security Journey](https://kerrsecure.com/2022/08/28/what-i-learned-in-year-one-of-my-security-journey/)". Here is my list of lessons learned in Year 2 as CEO of Security Journey: 1. **112 hours of work per week is not required for success.** Don't get me wrong, I spend a lot of time focused on my startup. But, I also run a martial arts school (that I do for fun) and coach my daughter's high school basketball team. My work-life balance is about flexibility. This does sometimes translate into working strange hours and getting things done at 10 PM, but I'm okay with that. 2. **Bad health habits are easy to develop and blame on the startup.** Yes, there is more stress than a normal job. This is not a valid excuse for skipping exercise and making poor food choices. I've put away my habits of healthy eating and exercise, and I realize that I must change in year 3 to truly be successful. 3. **Serving both the individual and Enterprise markets is difficult.** When we started, our vision was to provide both an individual application security training option as well as a solution for Enterprise. I've learned (through mentors and self-examination) that it is difficult to serve both markets well, and that our sweet spot is in the small / medium / and large Enterprise space. 4. **Product development and consulting are different hats and must be prioritized separately.** In past years I've blended these two activities together and focused more on consulting. For year 3, I'll dedicate more time to product development while still working with the consulting customers that have contributed to our success. 5. **Partnerships with other startups provide limited returns.** In our first two years, we've had different partnership opportunities arise with other startups, and none of these have come to any form of fruition. I'm learning that at this stage, it's better to focus on the things we can control, versus spending time developing a company-to-company partnership. For year 3, if there is money laying on the table, then we can talk. 6. **Sales require dedicated blocks of time.** I'm still not as hyper-focused on the sales process as I must be. I'll continue to develop this and focus specific amounts of time each week on sharing our solution with new potential customers. I'm good at speaking at conferences and meeting potential customers through that avenue. I struggle to develop leads outside of that channel. 7. **Finding the right freelancers is crucial.** We are a small startup (2 people) and do not have a dedicated development team. For us, freelancers are how we get new features developed and test automation built. We've worked with some freelancers that did not make the cut and others that are awesome. (Our current group is awesome!) The right freelancers allow us to move our product forward while still managing the bottom line. 8. **Marketing does not require a huge budget.** While still at Cisco and traveling the globe to promote product security, my friend Tony Vargas jokingly pointed out that he and I were marketing people. This was so true then, and even more true now. Marketing for us does not mean spending 10's of thousands of dollars per month. We approach marketing by hosting the Application Security PodCast and speaking at various security conferences around the world. We use a tool called MeetEdgar to manage our social media accounts and re-post evergreen content, all automatically. --- ### What I Learned in Year One of MY "Security Journey" - URL: https://kerrsecure.com/2022/08/28/what-i-learned-in-year-one-of-my-security-journey/ - Published: 2022-08-28 - Subject: The Security Journey Years - Series: The Security Journey Years, part 2 - Author: Chris Romeo It has been almost a year since I left my cushy job at Cisco Systems and embarked on my own "Security Journey" as CEO of my own company. I'm writing this down as much for myself as for anyone who might read it. I'm writing this to remind myself of what I've learned in the last year, and to chronicle some of the challenges of launching Security Journey. To quickly catch up on where this story started, read [The Day I met John Chambers... and Quit](https://kerrsecure.com/2022/08/28/the-day-i-met-john-chambers-and-quit/). I wonder if [John Chambers](http://www.linkedin.com/in/johnchamberscisco) ever read that article, or if he'll read this one? Here is my list of lessons learned in Year 1 as CEO of Security Journey: 1. **The Sales cycle is long**. When people tell you to not expect to have any money coming inbound for 6 months, they are speaking the truth. We were lucky to have a friendly partner bring us in on a project that allowed us to earn a bit of money to sustain life in the early days. 2. **Book knowledge of sales does not equal the ability to sell.** The CEO must be the chief salesperson in the beginning, and the lessons I've learned about sales have come from the school of hard knocks. Sales are about grinding as much as it's about skill and finesse. Some days it's just about reaching out to someone, even though I am sure that they hate me for e-mailing or calling them ONE MORE TIME. 3. **The strength of the sales funnel makes or breaks a product aimed at individuals.** A sales funnel is the idea that you take a prospect on a journey from when they learn about your product until they give you some money. The sales funnel connects websites with email and ultimately your product. We've experimented with lots of tools, and have landed on [Lead Pages](http://www.leadpages.net/) and [Drip](http://www.drip.co/) as our tools of choice to engage one-on-one with customers. 4. **Pricing of services results in some trial and error**. As I look back, I'm embarrassed by one of the first proposals I wrote. I scoped an entire (almost lifetime) engagement between a customer and me. Of course, they balked at the cost. I learned the importance of selling an entry-level engagement and building trust. After they see that we are for real and what we can do, then we can talk long-term. 5. **My personal brand developed via the security conference circuit and the Cisco name came up much shorter than I imagined**. It didn't hurt that I had worked to get my name out across the industry and carried the title of Chief Security Advocate at Cisco, but it did not carry me as far as I thought it would. 6. **Learning a programming language (Ruby on Rails) is very rewarding and cost-effective**. When you don't need outside consultants to fix a bug in your web application, you can use those funds to eat. Since becoming semi-proficient, I've done all my own feature work for the Security Journey web app. 7. **Grinding needs to be a way of life**. If the startup life was easy, everyone on earth would have one, and nobody would work for anyone else. Grinding is the process of rolling up the sleeves and going to work. Sometimes I dive deep into Marketing or Sales or Social, things I didn't use enter this game knowing much about. 8. **Startups can be a dark place some days**. And a bright place on other days. If you do this, there will be days when you think all hope is lost. Once or twice this past year, I've looked at my wife and COO ([Deb Romeo](http://www.linkedin.com/in/deb-romeo-23527b24)) and said, "I need to go back to work." I'd be lying if I told you this didn't happen. We are lucky that things have worked out, and now we have a stable income stream, and resources to focus on connecting our product to those who need it. I'm hoping that this information will help someone, but I know it wouldn't have helped me. I could have read this stuff on multiple sites, but I wouldn't have taken it to heart because I had to experience it firsthand for it to change me. If you experience this in the future or have experienced it in the past, drop me a note and let me know how it went for you. --- ### The day I met John Chambers.... and quit - URL: https://kerrsecure.com/2022/08/28/the-day-i-met-john-chambers-and-quit/ - Published: 2022-08-28 - Subject: The Security Journey Years - Series: The Security Journey Years, part 1 - Author: Chris Romeo _Chris Romeo, John Chambers, Marty Loy_ The day was November 5, 2015, and the place was San Jose, California. I was hosting Cisco SecCon 2015. SecCon is the yearly Cisco internal security conference where the power players gather together. I've directed a team of volunteers that deliver the conference for the past two years. Our keynote speaker for the day was John Chambers, Executive Chairman of Cisco Systems, and Chief Executive Officer for 20+ years. Prior to the official start of the day, I found myself in a room with John and the emcee. I was quiet for most of the 30 minutes, listening and a bit in awe of Mr. Chambers. I learned that he is just a regular guy. While I thought he would be very reserved, I was mistaken. He was cracking jokes and having a good time. Don't get me wrong, he was very focused on his preparation process, as he studied through his dossier, occasionally asking a question to help him better understand the audience. Chambers took the stage following his introduction, and delivered an exceptional keynote, roaming the room and interacting with the audience. This was my first time watching him live, and his ability to own the room was worth the price of admission for an aspiring speaker like myself. After he concluded his Q+A, he stuck around, handing out annual security awards. I was sitting in the front row as the event organizer, just taking in the entire scene and congratulating the winners as they returned to their seats in the front row. After the prepared awards, the Director began to announce another award. This award described an individual who had contributed greatly to moving security forward within the walls of Cisco. The Director went as far as calling this person "the face of security inside of Cisco". Then he called my name. I was in shock for a second. I managed to stand and accept the award. I was flattered to receive a standing ovation in front of 500+ people. As I was standing center stage for the picture, Chambers leaned over and whispered "Enjoy this moment. Enjoy the recognition your peers are giving you right now." I will never forget that guidance as long as I live. It is so important to stop every now and then and enjoy the positive moments we have in our careers. They may not always be on a stage in front of five hundred people, but that is okay. Enjoy the good moments. You're probably wondering where the "quit" part of the story comes in. After receiving the award and lunch at the conference, I asked my Director if he and I could sit down for a few minutes. I told him it was time for me to go. I did not quit as a result of anything that happened that day. I quit Cisco because it was time for me to move on in order to grow my career. I love Cisco, but I had outgrown it. I've entered the world of the startup. The world of challenge and potential hardship, but I did it because I believe in the ideas that I have. I believe that organizations want and need to build secure products and services. I believe that application security awareness is the answer and that Security Journey is the right company, based on my experience at Cisco, to make application security awareness a reality. --- ## Speaking 25 distinct talks, delivered 58 times since 2014. Grouped by talk rather than by date because several toured. Every delivery below is either sourced to a page naming both Chris and the talk, or explicitly marked as resting on his own confirmation. Where no recording or deck exists, the reason is stated — an absence here is a finding, not a gap in the research. Chris is booking speaking engagements for 2027. Chris Romeo is a third-time cybersecurity founder, now building a new company in application security and AI. He founded Security Journey and led it to an exit in 2022, then co-founded Devici, which exited in 2025. Chris has thirty years in security, including time as Chief Security Advocate at Cisco, and has spoken at RSA Conference every year from 2015 to 2025. He co-hosts The Application Security Podcast and AI Security Table. Current speaking topics: - **Securing AI agents**: How to secure AI agents, control their access to tools and data, and assess the risks of the actions they take. - **How AI changes the AppSec program**: How application security programs can adapt their practices and priorities as teams build with AI. - **AI-written code**: How to review and secure AI-written code, with checks that help developers find security problems before they ship. - **Building security champion programs**: How to build security champion programs that give developers practical skills and support for securing their software. - [Speaker page](https://appsecpodcast.com/speaking/chris-romeo/) - [Sessionize](https://sessionize.com/chris-romeo) - [The Application Security Podcast](https://appsecpodcast.com/) - [AI Security Table](https://securitytable.ai/) ### The Next Twenty Years: What AppSec Needs to Do to Cement the Future - URL: https://kerrsecure.com/speaking/next-twenty-years/ - Delivered: 2025 - Deliveries: 1 Twenty years of application security produced a profession, a toolchain and a standards body. An argument about what the next twenty have to produce instead. - RSA Conference USA 2025 — San Francisco, CA - source: https://path.rsaconference.com/flow/rsac/us25/FullAgenda/page/catalog/session/1727440546316001y9fK - recording: https://www.rsaconference.com/Library/presentation/USA/2025/The%20Next%20Twenty%20Years%20What%20AppSec%20Needs%20to%20Do%20to%20Cement%20the%20Future (gated, RSAC) ### The Startup Operating System - URL: https://kerrsecure.com/speaking/startup-operating-system/ - Delivered: 2025 - Deliveries: 1 How a security startup actually runs, from someone who has built and sold two — delivered to RSAC’s innovation track rather than its AppSec one. - RSA Conference USA 2025 — San Francisco, CA - source: https://path.rsaconference.com/flow/rsac/us25/FullAgenda/page/catalog/session/1727478692516001COfc - recording: https://www.rsaconference.com/Library/presentation/USA/2025/The%20Startup%20Operating%20System (gated, RSAC) ### Secure and Privacy by Design Converge with Threat Modeling - URL: https://kerrsecure.com/speaking/secure-and-privacy-by-design-converge/ - Delivered: 2024 - Deliveries: 1 Security by design and privacy by design are the same discipline wearing different badges, and threat modeling is where they meet. - RSA Conference USA 2024 — San Francisco, CA - source: https://www.youtube.com/watch?v=xX9HRsb_TBA - slides: https://static.rainfocus.com/rsac/us24/sess/1696098063653001DHln/finalwebsite/2024_USA24_DAS-W09_01_Secure-and-Privacy-by-Design-Converge-with-Threat-Modeling_1713996367361001ZSOs.pdf ### Why the “Secure by Design” pledge won’t save us from AppSec failures - URL: https://kerrsecure.com/speaking/secure-by-design-pledge/ - Delivered: 2024 - Deliveries: 1 A pledge is not a practice. What signing up to secure-by-design actually costs, and why most of the organisations that signed will not pay it. - The Elephant in AppSec Conference 2024 — Virtual - source: https://www.youtube.com/watch?v=HR8sel0fVZM ### The Paradox of Secure and Private by Design and Default - URL: https://kerrsecure.com/speaking/paradox-of-secure-and-private-by-design/ - Delivered: 2024 - Deliveries: 2 Secure by design and private by design pull against each other more often than the pledges admit. Where the tension is real, and how to decide it. - Triangle InfoSeCon 2024 — Raleigh, NC - no recording — Triangle InfoSeCon publishes slides rather than video, and discontinued its paid video packages in 2023. Listed on Chris’s own confirmation. - InfoSec World 2024 — Lake Buena Vista, FL - source: https://events.infosecworldusa.com/2024event/session/2225998/the-paradox-of-secure-and-private-by-design - no recording — InfoSec World records for its paid attendee portal only; nothing is published publicly. ### The Modern Application Security Rocket Ship - URL: https://kerrsecure.com/speaking/modern-appsec-rocket-ship/ - Delivered: 2024 - Deliveries: 1 Where application security is actually going, as against where the vendor floor says it is going. - InfoSec World 2024 — Lake Buena Vista, FL - source: https://events.infosecworldusa.com/2024event/session/2225964/the-modern-application-security-rocket-ship - no recording — InfoSec World records for its paid attendee portal only; nothing is published publicly. ### Zero Trust Threat Modeling - URL: https://kerrsecure.com/speaking/zero-trust-threat-modeling/ - Delivered: 2023 - Deliveries: 4 Zero trust is an architecture claim. Threat modeling is how you find out whether the claim is true of the thing you actually built. - OWASP Global AppSec DC 2023 — Washington, DC - source: https://www.youtube.com/watch?v=UW307y9aZMg - slides: https://static.sched.com/hosted_files/owasp2023globalappsecwashin/bb/Global_AppSec_DC%20-%20Zero%20Trust%20Threat%20Modeling.pdf - ISC2 Security Congress 2023 — Nashville, TN - source: https://events.isc2.org/p/s/zero-trust-threat-modeling-5847 - recording behind a free account on ISC2 - ISC2 Security Congress 2023 · virtual re-delivery — Virtual · November 2023 - source: https://events.isc2.org/p/s/zero-trust-threat-modeling-6248 - recording behind a free account on ISC2 - InfoSec World 2023 · Zero Trust Summit — Lake Buena Vista, FL - source: https://events.infosecworldusa.com/2023event/session/1076805/zero-trust-summit - no recording — InfoSec World records for its paid attendee portal only; nothing is published publicly. ### The Application Security State of the Union - URL: https://kerrsecure.com/speaking/appsec-state-of-the-union/ - Delivered: 2023 - Deliveries: 5 An annual survey of what changed in application security, what did not, and which of the two is being oversold. Delivered five times in 2023, retitled slightly at each. - RSA Conference USA 2023 — San Francisco, CA - source: https://www.youtube.com/watch?v=zav-3LpUxQ4 - slides: https://static.rainfocus.com/rsac/us23/sess/1664932746629001unE5/finalwebsite/2023_USA23_DAS-M05_01_The_Application_Security_State_of_the_Union_1682344881563001po4m.pdf - ISC2 Security Congress 2023 — Nashville, TN - source: https://events.isc2.org/p/s/the-application-security-state-of-the-union-5846 - recording behind a free account on ISC2 - Triangle InfoSeCon 2023 — Raleigh, NC - no recording — Triangle InfoSeCon publishes slides rather than video, and discontinued its paid video packages in 2023. Listed on Chris’s own confirmation. - InfoSec World 2023 — Lake Buena Vista, FL - source: https://events.infosecworldusa.com/2023event/session/1499076/the-application-security-state-of-the-union - no recording — InfoSec World records for its paid attendee portal only; nothing is published publicly. - GRITS Conference 2023 — Morrisville, NC - no public record survives; listed on Chris's own confirmation ### Open Source Software: The Good, The Bad, The Ugly - URL: https://kerrsecure.com/speaking/open-source-good-bad-ugly/ - Delivered: 2023 - Deliveries: 1 A panel with Shannon Lietz and Ryan Skinner on what the industry gets wrong about depending on code it did not write. - ISC2 Spotlight: Secure Software Development — Virtual · November 2023 - source: https://events.isc2.org/p/s/open-source-software-the-good-the-bad-the-ugly-6063 - recording behind a free account on ISC2 ### Ten DevSecOps Culture Failures - URL: https://kerrsecure.com/speaking/ten-devsecops-culture-failures/ - Delivered: 2022–2023 - Deliveries: 2 Ten ways a DevSecOps programme dies, each one taken from a real team, and what the failure looked like from the inside. - OWASP Global AppSec Dublin 2023 — Dublin, Ireland - source: https://www.youtube.com/watch?v=E03Iy2CD8AU - slides: https://hosted-files.sched.co/owasp2023globalappsecdublin/59/ROMEO_DevSecOps%20Fails%20_Global_AppSecDublin_Presentation.pdf - InfoSec World 2022 — Lake Buena Vista, FL - source: https://events.infosecworldusa.com/2022event/speaker/485925/chris-romeo - no recording — InfoSec World records for its paid attendee portal only; nothing is published publicly. ### Elite Security Champions Build Strong Security Culture - URL: https://kerrsecure.com/speaking/elite-security-champions/ - Delivered: 2022 - Deliveries: 4 What separates a security champions programme that changes how developers work from one that produces a mailing list. - RSA Conference USA 2022 — San Francisco, CA - source: https://www.youtube.com/watch?v=9gVM93a1H1I - ISC2 Security Congress 2022 — Las Vegas, NV - source: https://events.isc2.org/p/s/elite-security-champions-build-strong-security-culture-5592 - recording behind a free account on ISC2 - OWASP LASCON 2022 — Austin, TX - source: https://www.youtube.com/watch?v=-J5XXmOEAss - All Day DevOps 2022 — Virtual - source: https://web.archive.org/web/20221002124814/https://www.alldaydevops.com/addo-speakers/chris-romeo - no recording — All Day DevOps never published a 2022 on-demand archive; its recordings sat behind free registration. ### Using the Threat Modeling Manifesto to Build an Enterprise Threat Modeling Program - URL: https://kerrsecure.com/speaking/threat-modeling-manifesto-enterprise-program/ - Delivered: 2021–2022 - Deliveries: 2 Taking the Manifesto from a set of values to a programme that survives contact with an enterprise change process. - InfoSec World 2022 — Lake Buena Vista, FL - source: https://events.infosecworldusa.com/2022event/speaker/485925/chris-romeo - OWASP LASCON 2021 — Austin, TX - source: https://www.youtube.com/watch?v=jeHL8PXtezc ### Developers Dislike Security: Ten Frustrations and Resolutions - URL: https://kerrsecure.com/speaking/developers-dislike-security/ - Delivered: 2021 - Deliveries: 2 Ten specific things security teams do that developers hate, and what to do instead of each one. - RSA Conference USA 2021 — Virtual - source: https://www.youtube.com/watch?v=nN7NH752onk - slides: https://static.rainfocus.com/rsac/us21/sess/1602603671535001z2X2/finalwebsite/2021_US21_DSO-T19_01_Developers-Dislike-Security-Ten-Frustrations-and-Resolutions_1620743028250001aZP8.pdf - ISC2 Security Congress 2021 — Virtual - source: https://events.isc2.org/p/s/developers-dislike-security-ten-frustrations-and-resolutions-987 - recording behind a free account on ISC2 ### DevSecOps Culture: Laughing Through the Failures - URL: https://kerrsecure.com/speaking/devsecops-culture-laughing-through-failures/ - Delivered: 2021 - Deliveries: 1 The failures are funnier in hindsight and more useful than the success stories. - All Day DevOps 2021 — Virtual - source: https://web.archive.org/web/20210921105919/https://www.alldaydevops.com/addo-speakers/chris-romeo - no recording — A recording was published and has since been destroyed — the whole ADDO 2021 video archive was purged and the asset now returns “Video Not Found”. ### 10 Things I Wish Every Developer Knew about Security - URL: https://kerrsecure.com/speaking/ten-things-developers-should-know/ - Delivered: 2020 - Deliveries: 3 The ten things that would prevent most of what application security teams spend their week on. - RSA Conference USA 2020 — San Francisco, CA - source: https://www.youtube.com/watch?v=g9N1Aqehy5I - slides: https://static.rainfocus.com/rsa/presentations/USA20/2020_USA20_hum-w01_01_10-things-i-wish-every-developer-knew-about-security.pdf - Triangle InfoSeCon 2020 — Raleigh, NC - source: https://www.youtube.com/watch?v=ahmR37E5bsk - Triangle InfoSeCon 2019 — Raleigh, NC - slides: https://web.archive.org/web/20240518002504id_/https://www.triangleinfosecon.com/wp-content/uploads/2019/11/Chris-Romeo-InfoSecon-The-Ten-Things-I-Wish-Every-Developer-Knew-About-AppSec-OWASP-Proactive-Controls.pdf (Given there as “…About #AppSec: The OWASP Proactive Controls”.) ### Cheaper by the Dozen: Application Security on a Limited Budget - URL: https://kerrsecure.com/speaking/cheaper-by-the-dozen/ - Delivered: 2019–2020 - Deliveries: 2 Twelve things worth doing when the application security budget is nothing, ordered by what they return. - FIRST Regional Symposium 2020 — Durham, NC - slides: https://web.archive.org/web/20240705090000id_/https://www.first.org/resources/papers/durham2020/Romeo_Cheaper_by_the_dozen.pdf (Given there as “A baker’s dozen: application security on a limited budget”.) - RSA Conference USA 2019 — San Francisco, CA - source: https://www.youtube.com/watch?v=9jLQQ8570cU - slides: https://static.rainfocus.com/rsa/presentations/USA19/2019_USA19_hum-r02_01_cheaper-by-the-dozen-application-security-on-a-limited-budget-copy1.pdf ### Security Culture Hacking: Disrupting the Security Status Quo - URL: https://kerrsecure.com/speaking/security-culture-hacking/ - Delivered: 2018 - Deliveries: 2 Culture change treated as an engineering problem — find the pressure points, apply force there. - RSA Conference USA 2018 — San Francisco, CA - source: https://www.youtube.com/watch?v=fR_A-Xlmsp4 - slides: https://static.rainfocus.com/rsa/presentations/USA18/2018_USA18_hum-r14_01_security-culture-hacking-disrupting-the-security-status-quo.pdf - OWASP AppSec USA 2018 — San Jose, CA - source: https://www.youtube.com/watch?v=7AugFoQMQIQ ### Building an AppSec Program with a Budget of $0: Beyond the OWASP Top 10 - URL: https://kerrsecure.com/speaking/appsec-program-budget-of-zero/ - Delivered: 2018 - Deliveries: 3 The OWASP projects nobody talks about, assembled into a programme that costs nothing but time. - SOURCE Mesa 2018 — Mesa, AZ - no public record survives; listed on Chris's own confirmation - Triangle InfoSeCon 2018 — Raleigh, NC - slides: https://web.archive.org/web/20240812153749id_/https://www.triangleinfosecon.com/wp-content/uploads/2018/11/Chris-Romeo-Building-an-AppSec-Program-with-a-Budget-of-0.pdf - OWASP AppSec EU 2018 — London, UK - source: https://www.youtube.com/watch?v=5RmHQKeXgk4 - slides: https://2018.appsec.eu/presos/DevOps_Buiding-an-AppSec-Program_Chris-Romeo_AppSecEU2018.pptx (PowerPoint, 65 MB — the conference published no PDF of it.) ### How to Transform Developers into Security People - URL: https://kerrsecure.com/speaking/transform-developers-into-security-people/ - Delivered: 2017–2018 - Deliveries: 4 Not "train developers on security" — actually change what they care about, which is a different and harder task. - NDC TechTown 2018 — Kongsberg, Norway - source: https://www.youtube.com/watch?v=QtuvfNDC6cw - RSA Conference USA 2017 — San Francisco, CA - source: https://www.youtube.com/watch?v=btnBUWqJ0Oc - slides: https://static.rainfocus.com/rsa/presentations/USA17/2017_USA17_hum-r02f_01_how-to-transform-developers-into-security-people.pdf - ConVerge Detroit 2017 — Detroit, MI - Raleigh ISSA chapter — Raleigh, NC - source: https://www.youtube.com/watch?v=qKOyCQsLpw4 ### AppSec Behaviors for DevOps Breed Security Culture Change - URL: https://kerrsecure.com/speaking/appsec-behaviors-for-devops/ - Delivered: 2017–2018 - Deliveries: 3 The specific behaviours, at the level of what someone does on a Tuesday, that move a DevOps team’s security culture. - FIRST Regional Symposium 2017 — Raleigh, NC - slides: https://web.archive.org/web/20240629112451id_/https://www.first.org/resources/papers/raleigh2017/Romeo-Chris-Appsec-Behaviors.pdf (The only published deck of this talk anywhere.) - SOURCE Phoenix 2018 — Mesa, AZ - source: https://www.youtube.com/watch?v=lThR6p1oQ4Y - ConVerge Detroit 2017 — Detroit, MI ### AppSec Awareness: A Blue Print for Security Culture Change - URL: https://kerrsecure.com/speaking/appsec-awareness-blueprint/ - Delivered: 2016 - Deliveries: 4 The blueprint drawn from building Cisco’s programme, given four times on two continents — and his first talk at RSA Conference. - RSA Conference USA 2016 — San Francisco, CA - source: https://web.archive.org/web/20160318200248/http://www.rsaconference.com/events/us16/agenda/sessions/2554/appsec-awareness-a-blueprint-for-security-culture - slides: https://www.slideshare.net/slideshow/appsec-awareness-a-blueprint-for-security-culture-change/59363004 (The RSAC-hosted copy is gone; this mirror survives on CISO Platform’s account, and its title slide is the only place the session code HUM-T11 appears. All 54 slides render, but SlideShare gates the download — for the file itself, use the AppSec EU 2016 copy of the same talk.) - no recording — RSAC’s library does not reach back past 2017, and this session is not in it. Only the slide deck survives. - OWASP AppSec EU 2016 — Rome, Italy - source: https://www.youtube.com/watch?v=nWZaap-wejM - slides: https://2016.appsec.eu/wp-content/uploads/2016/07/AppSecEU2016-Chris-Romeo-AppSec-Awareness.pdf - RVAsec 2016 — Richmond, VA - source: https://www.youtube.com/watch?v=tDI1wFqJ0ME - slides: https://web.archive.org/web/20240411122012id_/http://rvasec.com/slides/2016/Chris%20Romeo%20RVASec-ROMEO-Appsec%20Awareness%20Blueprints.pdf (RVAsec’s own copy now 404s; this is the archived original.) - ConVerge Detroit 2016 — Detroit, MI - slides: https://speakerdeck.com/edgeroute/converge-detroit-2016-appsec-awareness-a-blueprint-for-security-culture-change ### Cisco’s Security Dojo: Raising the Application Security Awareness of 20,000+ - URL: https://kerrsecure.com/speaking/ciscos-security-dojo/ - Delivered: 2015–2016 - Deliveries: 4 The programme that trained twenty thousand engineers, and what breaks at that scale that does not break at two hundred. - RSA Conference USA 2015 — San Francisco, CA - slides: https://docs.huihoo.com/rsaconference/usa-2015/hum-t08-cisco-security-dojo-raising-the-technical-security-awareness-of-20000.pdf (Session HUM-T08. RSAC’s own copy is long gone; this mirror is the only one that survives.) - ISC2 Security Congress 2015 — September 2015 - no public record survives; listed on Chris's own confirmation - FIRST Regional Symposium 2016 — Raleigh, NC - slides: https://web.archive.org/web/20220425172844id_/https://www.first.org/resources/papers/raleigh2016/romeo-slides_20160219.pdf - OWASP AppSec USA 2015 — San Francisco, CA - source: https://appsecusa2015.sched.com/list/descriptions/ - no recording — OWASP published roughly 24 of that year’s 60 sessions and this was not among them. ### Application Security Awareness: Building an Effective and Entertaining Security Training Program - URL: https://kerrsecure.com/speaking/appsec-awareness-training-program/ - Delivered: 2015 - Deliveries: 2 How twenty thousand Cisco engineers were taught security by a team that decided the training had to be entertaining — and the ten things that made it work. - Raleigh InfoSeCon 2015 — Raleigh, NC · October 2015 - no public record survives; listed on Chris's own confirmation - ConVerge Detroit 2015 — Detroit, MI · July 2015 ### DevOps & AppSec: Why They Matter in an IoT World - URL: https://kerrsecure.com/speaking/devops-and-appsec-panel/ - Delivered: 2014 - Deliveries: 1 A panel on what connected devices do to the argument for building security in, held while much of the industry still treated IoT as a fad. - ISC2 Security Congress 2014 — Atlanta, GA · September 2014 - no public record survives; listed on Chris's own confirmation ### Dysfunctional Testing - URL: https://kerrsecure.com/speaking/dysfunctional-testing/ - Delivered: 2014 - Deliveries: 2 Product-based penetration testing, and how much of it tests the wrong thing. - ISC2 webinar panel — November 2014 - no public record survives; listed on Chris's own confirmation - CodenomiCON 2014 — Las Vegas · during Black Hat, August 2014 - no public record survives; listed on Chris's own confirmation ### Training and workshops Hands-on formats rather than talks — Learning Labs, full-day training, and capacity-limited discussions. Listed separately on purpose: on several of these he is credited as facilitator or participant rather than speaker, and counting them as conference talks would overstate the record. The two full-day OWASP trainings are the other case — there he is the instructor. ### Threat Modeling Championship: Breaker vs. Builder - URL: https://kerrsecure.com/speaking/threat-modeling-championship/ - Format: 3-hour workshop · red team against blue team, against the clock - InfoSec World 2024 · Lake Buena Vista, FL · September 2024 - source: https://events.infosecworldusa.com/2024event/session/2225956/threat-modeling-championship-breaker-vs.-builder - no recording — InfoSec World records for its paid attendee portal only; nothing is published publicly. - RSA Conference 2024 · San Francisco, CA · May 2024 - source: https://www.rsaconference.com/library/presentation/usa/2024/threat-modeling-championship-breaker-vs-builder - no recording — RSAC’s library marks this “View Details” rather than “Watch Now” — no recording was published. ### Advanced Security Threat Modeling: Red vs. Blue - URL: https://kerrsecure.com/speaking/advanced-threat-modeling-red-vs-blue/ - Format: Learning Lab · co-facilitated with Michael Burch - RSA Conference 2023 · San Francisco, CA · April 2023 - source: https://www.rsaconference.com/library/presentation/usa/2023/advanced-security-threat-modeling-red-vs-blue - no recording — RSAC’s library marks this “View Details” rather than “Watch Now” — no recording was published. ### Security Threat Modeling - URL: https://kerrsecure.com/speaking/security-threat-modeling-lab/ - Format: Two-hour Learning Lab, run twice · co-facilitated with Michael Burch - RSA Conference 2022 · San Francisco, CA · June 2022 - source: https://www.rsaconference.com/library/presentation/usa/2022/security%20threat%20modeling - slides: https://static.rainfocus.com/rsac/us22/sess/1626838926667001AtVv/finalwebsite/2022_USA22_LAB3-W08_01_Security-Threat-Modeling_1655400976386001QCW8.pdf (The joint deck — its title slide credits Michael Burch alongside him.) - no recording — Run under Chatham House Rule — the session page asks that no recording of any sort take place. ### Hands-on Threat Modeling - URL: https://kerrsecure.com/speaking/hands-on-threat-modeling/ - Format: 2-hour workshop - DEF CON 30 AppSec Village · Las Vegas · August 2022 - source: https://www.appsecvillage.com/events/dc-2022/hands-on-threat-modeling - no recording — AppSec Village recorded that year’s talks but not its workshops. DEF CON’s own media archive holds ten AppSec Village videos and this is not among them. ### Building a World Class Security Champions Program - URL: https://kerrsecure.com/speaking/world-class-security-champions-program/ - Format: Birds of a Feather · facilitated discussion under Chatham House Rule - RSA Conference 2021 · May 2021 - source: https://www.rsaconference.com/Library/presentation/USA/2021/building-a-world-class-security-champions-program - no recording — A Birds of a Feather discussion under Chatham House Rule; not recorded. ### Building an AppSec Program on the Cheap with OWASP - URL: https://kerrsecure.com/speaking/appsec-program-on-the-cheap/ - Format: Peer2Peer discussion, capacity-limited · three annual runs - RSA Conference 2020 · February 2020 · as “Using Open Source and OWASP to Build an Application Security Program” - source: https://www.rsaconference.com/Library/presentation/USA/2020/using-open-source-and-owasp-to-build-an-application-security-program - no recording — RSAC’s library marks this “View Details” rather than “Watch Now” — no recording was published. - RSA Conference 2019 · March 2019 - source: https://www.rsaconference.com/Library/presentation/USA/2019/building-an-appsec-program-on-the-cheap-with-owasp - no recording — RSAC’s library marks this “View Details” rather than “Watch Now” — no recording was published. - RSA Conference 2018 · April 2018 - source: https://www.rsaconference.com/Library/presentation/USA/2018/building-an-appsec-program-on-the-cheap-with-owasp-2 - slides: https://speakerdeck.com/edgeroute/owasp-triangle-presentation (The same deck, from his OWASP Triangle chapter delivery in March 2018.) - no recording — RSAC’s library marks this “View Details” rather than “Watch Now” — no recording was published. ### Building an AppSec Program with OWASP - URL: https://kerrsecure.com/speaking/building-an-appsec-program-with-owasp/ - Format: Full-day training - OWASP Global AppSec DC 2019 · Washington, DC · September 2019 - source: https://globalappsecdc2019.sched.com/list/descriptions/ - no recording — A paid full-day training day. OWASP does not record those. ### Changing Security Culture - URL: https://kerrsecure.com/speaking/changing-security-culture/ - Format: Interactive table exercise · companion to the Security Culture Hacking talk - RSA Conference 2018 · April 2018 - source: https://www.rsaconference.com/Library/presentation/USA/2018/changing-security-culture-2 - slides: https://static.rainfocus.com/rsa/presentations/USA18/2018_USA18_lab1-t09_01_changing-security-culture.pdf - no recording — RSAC’s library marks this “View Details” rather than “Watch Now” — no recording was published. ### Threat Modeling: uncover vulnerabilities without looking at code - URL: https://kerrsecure.com/speaking/threat-modeling-without-code/ - Format: Workshop - NDC TechTown 2018 · Kongsberg, Norway - source: https://www.youtube.com/watch?v=Fmp9UFjPiJs ### AppSec Fundamentals - URL: https://kerrsecure.com/speaking/appsec-fundamentals/ - Format: Full-day training - OWASP AppSec USA 2017 · Orlando, FL · September 2017 - source: https://appsecusa2017.sched.com/list/descriptions/ - no recording — A paid full-day training day. OWASP does not record those. ### Chairing and programming ### ThreatModCon 2023 - URL: https://kerrsecure.com/speaking/threatmodcon-2023/ - Role: Founding team & emcee - When: Washington, DC · October 2023 The first conference ever dedicated to threat modeling. Chris was part of the team that founded it and emceed the inaugural edition, giving the opening and closing remarks and presenting the first Adam Shostack Award. His engagement with the conference ended after that edition. ThreatModCon ran the day after OWASP Global AppSec DC 2023, in the same city, and was the first time the threat modeling community had a conference of its own. Chris opened it and closed it. The opening is billed by the organisers as a keynote, but it is a shared panel — him alongside Adam Shostack, Brook Schoenfield, Matthew Coles, Seba Deleersnyder, Tanya Janca, Robert Hurlbut and John Taylor — so it is a host’s welcome rather than a solo keynote, and it is described that way here deliberately. - Opening remarks, and the “Threat modeling is for everyone” panel: https://www.youtube.com/watch?v=Z8hJWkbVXyU - Closing remarks, and the inaugural Adam Shostack Award: https://www.youtube.com/watch?v=59FjNNV0ups ### RSA Conference - URL: https://kerrsecure.com/speaking/rsac-program-committee/ - Role: Program Committee - When: 2016–2025 · DevSecOps & Application Security track Ten years on the committee that selects what RSA Conference programmes in application security — on the other side of the table from the speakers, deciding which talks the industry hears. RSAC publishes its committee roster per year and keeps no index of past members, so a decade-long role leaves very little searchable trace. The 2024 panel below is the one year with a primary source naming him; the span is on his own account. - The 2024 committee on the year’s DevSecOps and application security programme: https://www.youtube.com/watch?v=EmAwqS-Ap0M ### OWASP Triangle - URL: https://kerrsecure.com/speaking/owasp-triangle/ - Role: Chapter Lead - When: North Carolina Ran the local OWASP chapter — the unglamorous end of community work, and the end where people actually learn things. Self-reported, from the “About Chris Romeo” slide of his own RSAC 2020 deck. A chapter lead organises monthly meetings, finds speakers, and keeps a local security community alive between conferences. ### Cisco SecCon - URL: https://kerrsecure.com/speaking/cisco-seccon/ - Role: Organiser & Host - When: 2013–2015 Cisco’s internal security conference, run for an engineering population of tens of thousands. An internal conference at the scale of a mid-sized public one. He has written about that period, and about leaving it, in the essay linked below. - The day I met John Chambers and quit: https://kerrsecure.com/2022/08/28/the-day-i-met-john-chambers-and-quit/ ### Guest appearances On other people's shows. For the shows Chris hosts, see Podcasts below. - Security Champion Veterans Explain All — AI Cybersecurity Forum panel, with Dustin Lehr and Tanya Janca (April 2025) - https://newsletter.shehackspurple.ca/p/shehackspurple-april2025 - Supercharge Threat Modeling with Software Supply Chain Security — ReversingLabs, with Paul Roberts (October 2024) - https://www.youtube.com/watch?v=s5_qvZg_2e0 - Designing Secure and Private Software by Default — GitGuardian (August 2024) - https://www.youtube.com/watch?v=OQU66Ny22SE - Why “shift-left” isn’t good enough — The Elephant in AppSec (June 2024) - https://www.youtube.com/watch?v=WtgEKrlAx6o - RSAC 2024 Recap: Top Trends & Takeaways — ReversingLabs, with Tennisha Martin (May 2024) - https://www.reversinglabs.com/webinar/rsac-2024-recap - AppSec Unbounded: Embrace “Secure and Privacy by Design” — Webinar (April 2024) - announced and delivered; no public record found - Building a Successful Security Champions Program — Semgrep, with Tanya Janca (April 2024) - https://www.youtube.com/watch?v=nkzuUw8LQLA - AppSec and DevSecOps track discussion — RSA Conference livestream (March 2024) - announced and delivered; no public record found - The Role of AI in Application Security — Webinar (March 2024) - announced and delivered; no public record found - Threat Modeling Lab — a hands-on workshop — Threat Modeling Connect (February 2024) - https://www.youtube.com/watch?v=oioLnkQeVek - Shift Left? — The Hedge 212 — The Hedge, with Tom Ammon and Russ White (February 2024) - https://rule11.tech/hedge-212/ - The Great Debate: Does DAST work for DevSecOps? — NowSecure DevSecOps Bunch (January 2024) - https://www.youtube.com/watch?v=GwicIXUn3jw - Threat Modeling and Software Supply Chain Security — ReversingLabs, with Matt Rose (October 2023) - https://www.reversinglabs.com/webinar/threat-modeling-and-software-supply-chain-security - Threat Modeling Roundtable — NowSecure Connect 2023 (October 2023) - announced and delivered; no public record found - Building a Grassroots Security Champions Program — Champions of Security, with Dustin Lehr (June 2023) - https://podcasts.apple.com/us/podcast/building-a-grassroots-security-champions-program-w/id1681955280?i=1000617193216 - The state of application security — ConversingLabs Cafe (June 2023) - https://www.reversinglabs.com/conversinglabs/the-state-of-appsec - Learning Application Security — ScaleToZero (May 2023) - https://www.youtube.com/watch?v=ZQn_LPSGcqc - SBOMs, provenance, security champions and third-party risk — Third Party Threat Hunters (March 2023) - https://www.youtube.com/watch?v=XXWPsMMzWdk - The Security Champions Framework — The Security Champions Podcast (March 2023) - https://podcasts.apple.com/us/podcast/chris-romeo-the-security-champions-framework/id1677350416?i=1000606541489 - Threat Modeling Manifesto in a Mobile First World — NowSecure DevSecOps Bunch (March 2023) - https://www.youtube.com/watch?v=jgcO23RmSw4 - Application Security at Scale — Phoenix Security, with Francesco Cipollone (March 2023) - https://www.youtube.com/watch?v=wqlC-cClqYE - Threat Modeling with Chris Romeo — The Hedge 164 — The Hedge, with Tom Ammon and Russ White (February 2023) - https://rule11.tech/hedge-164/ - Chris Romeo Talks Security Journey Exit — The Friday Nooner (November 2022) - https://pod.co/the-friday-nooner/chris-romeo-talks-security-journey-exit - How a Cybersecurity Professional Broke Out as an Entrepreneur — Exit Stories (October 2022) - https://podcasts.apple.com/us/podcast/chris-romeo-how-a-cybersecurity-professional-broke/id1526276365?i=1000583012483 - Successes and Failures at Security Training — Open Security Summit, with Izar Tarandach and Dinis Cruz (September 2022) - https://open-security-summit.org/sessions/2022/mini-summits/sep/governance/successes-and-failures-at-security-training/ - DevSecOps Culture: Laughing Through the Failures — RSAC webcast series (July 2022) - https://www.youtube.com/watch?v=aSiRZNS0eEc - Threat Modeling for Product Managers — Product Momentum (April 2022) - https://itx.com/podcasts/threat-modeling-for-product-managers/ - Threat Modeling the Software — Down the Security Rabbithole (November 2021) - https://www.buzzsprout.com/2153215/episodes/12448724-dtsr-episode-471-tpa-threat-modeling-the-software - Chris Romeo and the State of Security — The Hedge 48 — The Hedge, with Tom Ammon and Russ White (August 2020) - https://rule11.tech/hedge-048/ - How to Transform Developers Into Security People — Secure Coding Virtual Summit (March 2021) - https://www.securecoding.com/events/virtual-summit-march-2021/ - The Threat Modeling Manifesto: From Theory to Practice — IriusRisk, with Alyssa Miller and Stephen de Vries (December 2020) - https://www.iriusrisk.com/webinars/the-threat-modeling-manifesto-from-theory-to-practice - Threat Modeling Manifesto launch panel — Open Security Summit (December 2020) - https://open-security-summit.org/sessions/2020/mini-summits/dec/threat-modeling/threat-modeling-manifesto/ - AppSec Awareness and Security Culture — The Right Security (November 2020) - https://www.youtube.com/watch?v=qrghck_JoVg - Things Every Developer Should Know About Security — Application Security Weekly (October 2020) - https://www.youtube.com/watch?v=afV8AdRmwJc - Creating Security Champions with Continuous Education in DevSecOps — DJ Schleen (March 2020) - https://www.youtube.com/watch?v=btt-7pIKWY4 - Building a Security Mindset — Beyond Disruption, AICPA & CIMA (May 2018) - https://beyonddisruption.libsyn.com/2018/05 - IoT Security: the Security Development Lifecycle Way — The IoT Business Show, with Bruce Sinclair (2017) - https://www.youtube.com/watch?v=NhJusyxHnw0 - On Changing Culture — Down the Security Rabbithole (July 2016) - https://www.buzzsprout.com/2153215/episodes/12448998-dtsr-episode-204-on-changing-culture - The Cisco Security Ninja program — Cisco TAC Security Podcast (October 2015) - https://community.cisco.com/t5/security-knowledge-base/tac-security-podcast-episode-47-the-cisco-security-ninja-program/ta-p/3157096 --- ## Podcasts ### The Application Security Podcast Chris Romeo and Robert Hurlbut invite AppSec experts to break a topic down to something you can use, in about forty-five minutes. - Site: https://appsecpodcast.com/ - Feed: https://feeds.buzzsprout.com/1730684.rss - Apple: https://podcasts.apple.com/us/podcast/application-security-podcast/id1154351685 - Spotify: https://open.spotify.com/show/4q9BxNrRb0NWnLBpSmNqoP ### AI Security Table (formerly The Security Table) Four industry veterans around one table, arguing about what actually happens when you try to build secure software. - Site: https://securitytable.ai/ - Feed: https://feeds.buzzsprout.com/2094080.rss - Apple: https://podcasts.apple.com/us/podcast/the-security-table/id1659280767 - Spotify: https://open.spotify.com/show/147seyy9rKauyoQxp0RM5A ### The Threat Modeling Podcast Short conversations with the people shaping how threat modeling is actually practised. - Site: https://threatmodel.buzzsprout.com - Feed: https://feeds.buzzsprout.com/2152378.rss - Apple: https://podcasts.apple.com/us/podcast/the-threat-modeling-podcast/id1680825552 - Spotify: https://open.spotify.com/show/5wB4EQzVlxkQhemETVRZvT ### Reasonable AppSec The weekly newsletter. https://appsec.beehiiv.com --- ## Services See https://kerrsecure.com/services/ and https://kerrsecure.com/llms.txt for what the consulting covers. Contact is hello@kerrsecure.com.