Adobe: Increasing transparency and the secure product lifecycle

Adobe: Increasing transparency and the secure product lifecycle

Adobe: Increasing transparency and the secure product lifecycle

Date: Aug 11, 2010

Brad Arkin discusses why Adobe created his role, how it engages the security research community and how Adobe has learned that talking about security isn't a bad thing.

View more in this series:


Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.     

Adobe: Increasing transparency and the secure product lifecycle

Interviewer: You came to Adobe two years ago; talk a little bit about some of the
challenges that you immediately had to address; why they
brought you on.

Brad Arkin: When I joined the firm, the role that I took on was a new role;
it was not like I was replacing someone. My management saw
that there was a need to really escalate the work that we
were doing around security. When they brought me onboard,
some of the things, like this media interview we are doing
right now, Adobe had never done a phone interview about
security before, in 2009 we probably did hundreds of them,
so that was a big change to get the company used to talking
about security. Since we are not a security company, it is
usually bad news.

It is really hard to explain, that although we wish the
security incident was not happening, it is much better to
talk about it, to be vocal about what users can do, than it
is to just give a short statement then try to melt away.
Becoming more open, more engaged with the security
community, and really looking for things that we can do in
order to go out and aggressively approve, both on the
engineering side, but also on the response side, and how
there is so much more we could be doing. It is really
opening our eyes to what was possible, and the potential
there, was one of the big challenges that I started with.

Interviewer: That is interesting. There is kind of two pieces; there is that
response side and the engineering side. In your role, do
you juggle both of those pieces?

Brad Arkin: Right. I am ultimately the exec responsible for all the aspects
of product security, there is a couple pieces to that.
There is the Adobe Secure Software engineering team, these
are the folks that work with the product teams on the
feature road map, things that we are doing. Some recent
examples are Sandboxing, that we announced last week for
Reader, that is a proactive mitigation technology. The new
updater that we put into Reader and Acrobat, things like
the JavaScript Blacklist Framework and some of the UI
changes around the yellow bar, these are all things in
Acrobat. We do proactive work like that with all of our
products: Flash Player Air, Shockwave Player, Full Fusion,
for all of these products we got people on the proactive
side on my team coordinating with security personnel that
are embedded within the product teams, so they do not work
for me, but we work very closely together to make sure they
have the support they need to get the job done. That is all
proactive.

On the reactive side, that is the product security incident
response team or PSIRT. These folks, if you send an email
to PSIRT@adobe.com, they are the ones that are going to
receive that email, triage it, work with the product teams
to get a fix scheduled, and then communicate with the
researcher the whole time through. The PSIRT folks are also
out there going to conferences and working with the
community to make sure that we understand where the threats
are going; new attack techniques or just, all sorts of
things that we need to worry about. Figuring out where
things are moving towards and how we can defend against
that.

The communications side of it, getting bulletins out,
writing on the blog, that sort of thing; people help out
from all parts of the team, but PSIRT drives all the
reactive communication in order to explain what mitigation
guidance we have and other information about any urgent
security vulnerabilities.

Interviewer: Was one of the main issues early on, communicating with the security
researcher community? Did they know, necessarily, before
you got there, who to go to if they did find a bug in
Acrobat Reader or any of the other products?

Brad Arkin: I think, actually, we have had a pretty effective relationship
with the security community, so that PSIRT mail alias has
been up and accepting communications for a long time. I am
not too sure, prior to the Macromedia/Adobe merger, because
a lot of things were brought together at that point, but we
have been, as a company, responding to responsibility to
disclose bugs for a long time, much longer than before I
started, but there is always a chance to educate more
people, let them know that we are really working on this.
You always have the potential for confusion where a
security researcher would try to submit a bug through a
regular bug process, and it does not get the same kind of
attention that we want to give to security bugs, so they
might get frustrated.

So one of the things we did about that was, in January '09, I
think it was the second blog post, we put on our asset
blog, which we just started up shortly after I joined, was
a step-by-step process of how we like to work with the
community. Just to lay it out and say this is the typical
flow: you give us something, we talk, we share with the
product team, we get schedules set, we talk with you about
it. That has been really useful, because when everyone asks
questions we say, 'Hey, check this out.' It is still
accurate today, so that has been really good.

More on Security Resources

  • canderson

    201 CMR 17 compliance: What you need to know

    VIDEO - The new Massachusetts data protection law, 201 CMR 17, is known as one of the most stringent laws of its kind. In this interview, David Navetta of the Information Law Group discusses how enterprises should approach compliance with this law.
  • canderson

    OWASP Security Spending Benchmarks Project

    VIDEO - An OWASP project investigates company spending on software development. A survey found a majority of firms getting an independent third-party security review of software code.
  • PKI (public key infrastructure)

    Definition - A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify the identity of the other party.
  • Pretty Good Privacy (PGP)

    Definition - Pretty Good Privacy or PGP is a popular program used to encrypt and decrypt email over the Internet, as well as authenticate messages with digital signatures and encrypted stored files.
  • firewall

    Definition - A firewall is a network security system, either hardware or software based, that controls incoming and outgoing network traffic based on a set of rules.
  • social engineering

    Definition - Social engineering is a non-technical method of intrusion hackers use that relies heavily on human interaction and often involves tricking people into breaking normal security procedures.
  • Advanced Encryption Standard (AES)

    Definition - The Advanced Encryption Standard or AES is a symmetric block cipher used by the U.S. government to protect classified information and is implemented in software and hardware throughout the world to encrypt sensitive data.

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: