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 firstname.lastname@example.org.
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
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
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
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
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.