Michael Burch

Application security lists, like the CWE Top 25 and Owasp Top 10, help focus on specific weaknesses or vulnerabilities within your system. But, do you understand their approach to ranking? If not, can you really trust them? Some vulnerability list ranking methodologies bias one aspect of security over another, and some may not work with partially unknown vulnerabilities. 

As the complexity of applications increases, so does your reliance on open source and third-party software libraries. With the compounded usage of open source, an expansion of the attack surface is underway. The increased threat is evident in recent high-profile attacks targeting the software supply chain. These types of attacks threaten organizations indirectly by targeting third-party vendors that provide you with software. Can you vouch for the security state of every library in your Rails applications? 

While the year 2020 is not one we'll soon forget, this was a year of extreme growth for SecurityJourney. It's incredible what a team can achieve with passion and an innovative, security culture-changing product. Here are a 8 key growth lessons I learned over the past year.

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: DevOps security culture.

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.

I've been working on Security belt programs for 10+ years. I've had the privilege to help build the Cisco Security Ninja program. I'm also continuing to develop our security belt platform at Security Journey. I've created over 500 pieces of learning content. I've created material and the assessment questions that go with it.

How do you incentivize people to participate in your security program? Are you using a carrot or a stick? Security rewards and recognition are crucial for the success of your security belt program.A security belt program is a level-based, achievement-oriented security educational experience. By creating a program with multiple levels, you provide your learners with the opportunity to make their way through the “journey.”

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.

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.

I'm two years into 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.

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 what I've learned in the last year, and to chronicle some of the challenges of launching Security Journey.

The day was November 5, 2015, and the place San Jose, California. I was hosting the 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.

This post is a result of a conversation on the Application Security Podcast. Adam Shostack joined Robert and me, and the topic was remote threat modeling. We're all living in this new world where we're working from home. The question we pose is, how will we make progress on rolling out threat modeling when we can't meet with people face to face and work directly on a whiteboard?

Everyone wants their engineering staff to be better at threat modeling. Security teams desire a world where developers practice a threat modeling mindset. A threat modeling mindset is where threat modeling is no longer a process or a tool but is instead a way of life. When developers embrace this mindset, they see threats jump off the page in both diagrams and code. They hear peers discussing a potential solution, and they can articulate the security challenges that such an approach will cause.

NOTE: This article is written based on a conversation on the Application Security Podcast with Matt McGrath, called “Security Coaches."Most developers will say security is a concern, but not always the first concern. Developers get hit by the business to deliver user stories quickly and in a state of completeness.

These are the top ten, most listened to episodes of the Application Security Podcast for calendar year 2019.

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.

Unlike wine and cheese, 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 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).

On this episode, Chris and Robert interviewed Steve Springett about the world of the secure supply chain.In part one of the series, we covered software supply chain risk, the depths of the software composition analysis market, and the current state of commercial and open-source SCA. Read part one first to set the stage on SCA and software supply chain risk.

When building a new program, many start here, thinking we'll just create a policy and then everyone will follow along and do the right thing for security. Unfortunately, an Executive's direction is not enough to change the security culture. It does not hurt along the way to have executive buy-in, but it won't kick start the program.

This series was born from an interview on the Application Security Podcast, season 5, episode 18. Chris and Robert interviewed Steve Springett about the world of the secure supply chain. In part one, we introduce the concepts of software supply chain risk and software composition analysis and cover the need to use multiple SCA tools.

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.

Are hacking and penetration testing the great solution to your security woes? That's what you'll hear from security conference speakers, who focus more on these topics than any other discipline in cybersecurity. That heavy focus on hacking is misguided.You can't hack yourself secure.

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 and delivery approaches and adopt a DevOps mindset.

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?

2018 was a great year for the Application Security Podcast. We completed season three and then launched season four (which will conclude in January 2019.)

Here are five things that have impacted me in my career, and helped me to grow both as a security person and a human being.

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.

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.

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. “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.

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.

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 process, and change how the developer approaches security decisions.

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.

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.

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.

When people think about application security in a large organization, big tech companies like Adobe, Cisco, Microsoft, and HPE often come to mind. These companies appear to have cracked the code on how to add security to the software development lifecycle (SDLC). They incorporate secure SDLC (S-SDLC), a series of steps and activities designed to eliminate as many threats and vulnerabilities from a product or application as possible prior to shipment or deployment. And they are vocal about their security programs, providing relevant details about security processes on their websites.

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.

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.