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