Want better security? Stop calling it research

The way we advocate for better security impacts our success.

What happens if you suggest your organization subject itself to security research? What sort of reaction do you think you’ll get? Better, how would you define and explain it? Why?

Contrast that to suggesting you enhance existing processes with stronger security measures — tailored to the needs of the organization. It’s a stronger approach. It leads to better integration of security. Imagine actually including security sooner in the process?

James Jardine (LinkedIn, @jardinesoftware) of Jardine Software penned a post last week laying out the difference (read it here). His take on the distinction between security research and testing lays out our opportunity. In fact, I see it as a way to speed up support for security research and other programs aimed at making it better for all of us.

Here are five questions with James about why the concept matters and how you can take advantage of it.

What inspired your recent article about the definitions of words and the impact on our efforts in security?

I read a tweet supporting the FDA push for medical device makers to allow security research. It caused me to step back to think about the phrase “security research.” Further, what does it actually mean to allow more security research? Given known issues with security protocols, devices, and applications, is what we need more research?

Instead of research, what if the statement read “FDA pushing for medical device makers to adopt stronger security testing”?

The security industry struggles to define security research. We offer “bug bounty” programs. Both offer value and introduce confusion. Businesses who seek better security know what QA is. They have programs to test and ensure a desired level of quality. Instead of focusing on research and bounties. If we focus on language and concepts they already have, we get more traction.

When looking at security research versus testing, what is the problem we’re trying to solve? What is the business need?

Security is a young field. It is still confusing to a lot of people. Defining security research is more complex. We’re debating it in the industry. In my view, security research plays a valuable role in identifying new challenges and advancing solutions.

Once the bug, vulnerability, or like is defined and validated, looking for it is the role of testing. Following established processes and methods to look for known potential defects within specific instances. For example, a medical device manufacturer could test for identified flaws for that type of device. This includes both common problems known to impact the class of device (like insecure transmissions or default passwords as well as anything specific to the device itself.

The business seeks quality. They don’t want to produce devices with known defects. Research identifies what testing looks for. This way research benefits the industry. And testers make sure the products meet the standard.

It comes down to quality. Do companies view testing different than research? Is this something we can exploit to improve security?

Organizations are under pressure to provide competitive solutions at reasonable prices. Companies care about security. They invest in and proudly tout their quality assurance programs. Many of these same companies invest in research — commonly called research and development.

Here’s the difference: research (and development) is a bet. It’s an investment in the future. Or several investments. The hope is for some small amount to pay off. Testing is about today. Ensuring the current code, products, or solutions meet an established standard.

What, then, is the push for security research asking for? While it’s not consistent, it appears that we seek protections to look for security issues without legal repercussion. While valuable in a broad sense, it’s not the same as incorporating security into existing testing processes.

Is it easier to include security into the testing process than trying to launch a new research-focused initiative?

It sure is. While each organization is different, it is often easier to incorporate security into the established testing process than it is to introduce a new security program. Even better, it means introducing security into the process earlier — with distributed ownership. It means security is integrated instead of a separate program.

Typically, in-house security teams are small in comparison to the development and testing teams. Most of the organizations I consult with are lucky if they have five people on their security team capable of supporting testing. Those same organizations have between 50 and 150 people focused on QA testing. Empowering those testers is a better way to improve security in the organization.

This has the added benefit of making it easier to incorporate third-party resources and external programs. For most this means penetration testers, external code review, and even bug bounty programs. Leveraging the existing program creates natural opportunities and defined situations where the additional experience and ability is welcomed — not fought.

How can a security leader get started?

Communication and understanding are the two biggest factors when getting involved with the application teams. This isn’t a situation to demand security involvement. Treat it like an opportunity to figure out how to help someone else solve their problem. Most application teams lack deep information security experience. Start by understanding how your solutions are designed, written, and tested. Learn about their pressures. Figure out how they get compensated.

Once you understand the environment, identify where, when, and how to introduce security. Plan to start small and support incremental steps. Realize that each step is an improvement for security where everyone benefits. A good starting place is handing off control and use of your security testing tools. Ease the transition — for your peace of mind, and theirs. This is a step that puts the power and responsibility closer to the source. As you continue to support them, you’ll be amazed at the depth of their questions. Plus, it frees up your team to go focus on other areas of value.

As you partner with your development and testing teams, look for opportunities to train. Consider the external resources that benefit the process. Imagine the power of those teams making the request — with your counsel — instead of security requiring it.

This is a dramatic way to increase security within your organization as a leader.