Having Trouble Starting Your Application Security Program? Beat Up Your Vendors!

reservoir_dogs_standoff

Starting an application security program can be very challenging. If you don’t know how to get started – or if you can’t seem to get any traction getting your organization to change its ways – consider changing your focus and instead beat up on your vendors.

Why Is Application Security Hard?

Creating an internal application security program is hard. You have to get development and IT operations teams to change the way they work and shoulder additional burdens. This will likely cost them time they didn’t allocate and money they didn’t budget. And the lines of business these teams support are often laser-focused on developing new features and capabilities to delight customers and compete in an increasingly-cutthroat competitive business environment. Organization that take their eye off the ball with regard to competition and innovation are destined to die off – quickly. Failing to properly address security concerns might kill you – someday. The immediacy of competition and innovation requirements and the remoteness of pain from security failures causes many organizations to view application security as a nice-to-do/good hygiene activity rather than an imperative.

Security teams are great at understanding risk, but they don’t tend to make money for their organizations. Instead, they are often perceived as the “department of ‘no’” – holding up key initiatives – and as a cost center. In a perfect world this wouldn’t be the case – security teams would be universally perceived as a trusted resource to rely on for sage advice about managing risk while enabling business in an uncertain and dangerous world. And in leading organizations this is the case. However – look at your security budget and think about how many times you have met with your CEO in the past year, and you may have an indicator of how “leading” your organization is when it comes to security and risk management.

So – if your security team isn’t at the “pointy end of the spear” in your organization, what can you do to to change the landscape? One possible answer: beat up your vendors.

Why Would Vendor Application Security Be Any Easier?

It is often easier to get vendors to comply with your security requests than internal teams because of the Golden Rule. And the Golden Rule is – for our purposes today – the group with the gold makes the rules. So let’s see how that works.

As discussed above, when you are negotiating with internal development teams and lines of business, security is perceived as a cost center and an impediment to accomplishing forward progress. To bend these teams to your will you have to use all of your guile and tricks but you will always be fighting an uphill battle. John Dickson’s whitepaper “Turning the Tide” provides strategies for fighting – and winning – this battle. But battles are hard.

When you start requiring vendors to meet security requirements, the balance of power shifts. Now you enlist your vendors’ salesforce as your allies. If procurements are being held up pending development and security teams meeting documented requirements, their sales people – whose commissions are being held up –  become your best enforcers. Rather than starting your application security journey by undertaking a major internal process improvement initiative, you can start improving the security of your application portfolio by changing a few lines in your procurement contracts.

What Should You Expect?

First of all, unfortunately this probably will not help you with your most critical applications at the outset. In many organizations, the riskiest applications holding the most sensitive data are developed in-house. Let’s not discount the value of accounting, ERP, and industry-specific applications you have deployed, but you also need to realize that your custom software is probably responsible for the majority amount of your risk, and this approach won’t start helping you address that just yet. But – at least this is a way to get started and a way to introduce the concept of applications putting your enterprise at risk.

Also, this works far better when onboarding new vendors because they’re looking for a sale and are inclined to make concessions to close the deal. Expect this approach to work less well with existing vendors because in those cases you already have a defined relationship and changing the terms is much harder.

Karma has a way of enforcing “what goes around comes around” (some who provided feedback on this post also suggested that “stuff rolls down hill”) so you should expect that this same request will be levied on you by your customers. Look forward to it! That will provide you with more ammunition to help accelerate your efforts to improve the security of the code you are developing. All of a sudden your company’s salesforce will be on your side in promoting secure software development. Because when the security of software is holding up sales, then software security suddenly becomes a “must do” rather than a “nice to do.”

In a perfect world, organizations would be more open to voluntarily evolving their practices to develop more secure software. Unfortunately, this often isn’t the case and in those situations, a focus on vendor and supply-chain software security can be a way to jump start progress, improving the security of at least some portion of your application portfolio.

Contact us for help keeping your vendors accountable for software security.

About Dan Cornell

A globally recognized application security expert, Dan Cornell holds over 15 years of experience architecting, developing and securing web-based software systems. As the Chief Technology Officer and a Principal at Denim Group, Ltd., he leads the technology team to help Fortune 500 companies and government organizations integrate security throughout the development process. He is also the original creator of ThreadFix, Denim Group's industry leading application vulnerability management platform.
More Posts by Dan Cornell

Leave a Reply

Your email address will not be published. Required fields are marked *