How to prevent a “security embarrassment?”

https://www.linkedin.com/pulse/20141028094659-7430592-how-to-prevent-a-security-embarrassment

On Oct 7, 2014, a security researcher, Jonathan Hall, posted details of a potential Bash/Shellshock vulnerability on Yahoo’s infrastructure:

• http://www.futuresouth.us/yahoo_hacked.html
• https://www.reddit.com/r/technology/comments/2ifbjb/yahoo_got_hacked_this_morning_hooray_for/

As it turned out, it was NOT a Bach/Shellshock issue. As Alex Stamos, Yahoo’s chief information security officer wrote, “it turns out that the servers were in fact not affected by Shellshock.” (see https://news.ycombinator.com/item?id=8418809). But, what happened is a lesson that should be studied. The anxiety was preventable ……

What is the real problem? 

When you look at Jonathan’s complaints, it was not about the vulnerability. Jonathan's anxiety was about the inability to get critical information to the right people inside Yahoo. The public “fire drill” and “security embarrassment” was preventable. Yahoo has one of the absolute best security teams in the industry. Using this example demonstrates how these security issues happen to the most prepared.

Understanding “Full Disclosure” 

People who find “vulnerabilities” now fall into two major camps. The first are the criminals looking to use the vulnerability to break into something. The second and much larger group are the white hats who find a problem and want it fixed. This later group wants to do the right thing. They want to get the details of a security issue into the hands of someone who can take action. They will try to contact the right people, use official channels, and use their contacts within the security community. When they hit a wall, they feel they have no other choice by to publicly “disclose” the vulnerability. This public disclosure is referred to as “full disclosure.” It is an indication of something being broken.

If a full disclosure happens to your organization, do not shoot the messenger. 99% of the time. it is a problem with your organization, not the person finding the vulnerability.

What can you do to prevent “full disclosures?” 

The following “security communications channel” best practices should be followed by operators, vendors, and any organization that has customers on the Internet.

1. /security web page (and security.example.com)

The /security web page will have as a minimum information to contact the security team inside the company. This can be as minimum as security@example.com, the phone number, and the PGP key. Most mature organizations will have a range of information, including the security/vulnerability policies, security organizations they are members, and other information help customers. 

2. /contact web page must link to the /security page.

One of the first places someone who has found a vulnerability will check is the company’s “/contact” page (i.e.something like www.example.com/contact). The /contact page is an opportunity to point them in the right direction (i.e. the /security page). The contact page is not owned by the security team, but it is important for the security team to ensure that people who submit issues via the contact page get directly alerted to the security team. 

3. Break the /security and security.example.com page into modules

A wide range of people with “security” problems will land on the /security page. Bounces are bad. It means someone with a security issue is not getting an answer they need and would lead to problems (customer problems, public vulnerability disclosures, etc). One provide technique is to break the page into modules - with each module focusing on a specific audience with a security issue. For example:

Customers with a “security problem” module. These are customers who have something they think is wrong with which ever service/product that is sold. This module is a self-help section that has knowledge and tools to help the customer figure out if there is truly a problem and what to do to resolve the problem. This module should then have a linked to customer support - allowing the customer to ask for help if it is not on the “self-help” module.

Customers seeking to improve their “security posture.” Customers would come to the /security page to get educate. What else can they do to enhance their security posture? This is often driven by some press visibility security event. The event gets people to question and look for information that will help them. Investing in this “security empowerment” module helps to prevent future issues and builds good will with customers.

Security Product Modules. Some would say that the /security page is not a place to “market” to customers. The reality inside organizations is that the product managers with security products will only support the /security page if they are allowed to participate. The image, reputation, and brand of the company are can be critically damage by a bad “security image.” So the reality is that the /security page is a form of “marketing.” Marketing that protects the brand and reputation of the organization. Security teams should work hand in hand with the product and marketing teams to do what is in the best interest to protect the organization and serve the customers.

Security Response Team Contact information. As mentioned earlier, this module would have the information for peers to reach into the organization and get to the right people who have the span of control to fix security issues.

Report a vulnerability modules. This is separate for a reason. It a module that focuses the person with a vulnerability with information to report the vulnerability. Multiple channels need to be provided - email, PGP, web form, and phone numbers are normal. Including the policies and procedures for vulnerability management would also be included on this module. For example, if someone reports the vulnerability, will the organization give them credit when it is disclosed? Links to any bug bound programs can be included on this page.

4. Work with the local CERT

Most countries have at least one national Computer Emergency Response Team (CERT). These teams become allies - allowing individuals who find a security problem to be able to report it through the national CERT. Some “finders” of vulnerabilities are more comfortable reporting through a 3rd party. CERTs are natural 3rd parties. For this to work, the CERTs need to know the security incident response team of the organization. Building a proactive relationship streamlines the communications channel for the time when a vulnerability is reported

5. Security Teams - Consistently Brief Teams throughout your Organization 

Notice what happened with Jonathan Hall and Yahoo. As soon as Jonathan E-mailed the CEO, someone in the CEO’s office immediately contacted Yahoo’s security team and action started (see the post from Alex Stamos). This internal action can only happen through diligence. The diligence of the internal security team and the diligence of the teams receiving the vulnerabilities details. This is where the security team needs to spend the time to communicate and empower their peers within their organization. They need to ensure everyone knows the security team, understand what the security team does within the team, how everyone has a “security role” in the organization, and how to contact the security team 24x7 365 days a year. 

The Extras

The top 5 are the key items provide the foundation. The apply to most organizations - be they a mobile operator, an application vendor, or a software company. There are some extras to consider depending on your organization. These help build a community of professionals who know how to contact your security team and look for the vulnerabilities.

Join Industry Forums that address security issues and vulnerabilities. Start with groups like FIRST (www.first.org) and then explore other groups. These group connect your security team to other security teams - sharing best practices and helping to build a security community.

Build a Bug Bounty Program. If you are a software company or an on-line service, seriously consider a bug bounty program. They have been working successfully and are one of the key paths for vulnerabilities to be reported.

Publish the Security and Vulnerability Disclosure Policy. Don’t wait for something to happen in the press and your customer start asking. The process of writing and then publicly publishing a security and vulnerability disclosure policy focuses the organization. It is a key part of the preparation process. 

Bottom Line

The Jonathan Hall/Yahoo anxiety might have been prevented. When you look at the above list, you find that Yahoo does all of the above and more. The fact that the Yahoo organization has already reviewed the entire infrastructure for Bash/Shellshock Vulnerability shows the seriousness and intensity placed on security at Yahoo. Their first reaction was “did we miss something” and then started to double-check their work. This would only happen with a proactive security organization.

Now imagine your organization that does none of the above. What would you do if someone knocked on your door trying to tell you about a major vulnerability? Remember, there is a market for vulnerabilities. The criminals want them and will exploit them (i.e. Target, Home Depot, etc.). The people who know on your door trying to report vulnerabilities are your allies.