Transcript of a discussion on how Twitter’s chief information security officer makes the most of APIs by better knowing and managing them across their full lifecycles.

1. Page 1 of 10
When it Comes to API Security,
Expect the Whole World to Be
Testing Your Mettle, Says Leading CISO
Transcript of a discussion on how Twitter’s chief information security officer makes the most of APIs by
better knowing and managing them across their full lifecycles.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable AI.
Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re
listening to BriefingsDirect.
For developers and business architects alike, they often don’t know how a technology has
adversely impacted a company -- until it has run amok. Just as cloud computing initially seeped
into organizations under the cloak of shadow IT, an application programming interface’s (API)
use in adoption has often followed an organic, inexact, and unaudited path.
IT leaders know they’re benefiting from APIs -- internal, via third parties, and often outwardly
exposed -- they just don’t know where they are, how much they support key services, and how
they’re being used … or abused.
Stay with us now as we explore how API-intensive and API-experienced businesses are
bringing maturity to their APIs’ methods and protections.
To learn how Twitter, a poster child for business-critical API use,
makes the most of APIs by better knowing and managing them
across their full lifecycles, we’re joined by several guests to
discuss API maturity. Please welcome Alissa Knight, recovering
hacker and partner at Knight Ink. Welcome, Alissa.
Alissa Knight: Thank you, Dana. I appreciate it.
Gardner: We’re also here with Rinki Sethi, Vice President and
Chief Information Security Officer (CISO) at Twitter. Welcome,
Rinki.
Rinki Sethi: Thanks, Dana. It’s nice to be here.
Gardner: Security researchers at Akamai in their latest state of the internet report detail how
cybercriminals have noticed APIs and are turning them into an attack vector. This in itself isn’t a
surprise, but the degree to which people are not prepared for it is.
Rinki, how do CISOs such as you at Twitter get the most out of APIs while limiting the risk?
Sethi: Securing APIs is a multi-layered approach. My philosophy is that APIs are meant to be
exposed. We expose APIs to enable developers to do amazing things on our platform.
Knight

2. Page 2 of 10
So, you need a multipronged approach to security. There are basic tools that help you prevent
risk around APIs, whether it’s volumetric attacks or the basic vulnerabilities and supporting the
infrastructure. But really, each API introduces its own risk, and there is a multi-layered approach
in how you go and secure that.
Gardner: Rinki, what’s your history as a CISO? And please tell us about your tenure at Twitter.
Sethi: I’ve been in the cybersecurity industry for almost two
decades now. I’ve been around the block at some really
great brands in the Bay Area, from working at eBay to Palo
Alto Networks to IBM.
I took my first CISO role almost three years ago at a start-up
company called Rubrik, a unicorn, and helped them after a
security breach and to scale up their security program. That
was my first role as CISO. Before that, I held various roles
leading product security, security operations, and
governance, risk, and compliance (GRC).
While at Rubrik, during early COVID, we had to scale back
and focus on how to thrive as a business. At that time,
Twitter reached out. I joined Twitter after the security breach
and before the U.S. election to help build out a scalable security program. And so, here we are.
I’m a little over a year into this role.
Gardner: The good news about APIs is they’re widely exposed and can be used productively.
The bad news is they’re greatly exposed. Knowing that and living with that, what keeps you up
at night? What’s a lingering concern when it comes to the use of APIs?
Decrease API vulnerability ASAP
Sethi: The explosion of APIs in use in just the last few years has been at an exponential rate.
Our traditional security products don’t protect us against business logic flaws -- and that’s what
keeps me up at night.
Business logic flaws can result in security or privacy violations for the consumer. And other than
unit testing -- and really looking at your APIs and testing them out for those business logic flaws
-- there’s not great innovation yet. There are [API security] companies starting up, and there are
going to be a lot of good things that come out, but we’re still early. That’s what keeps me up at
night. You still have to go back to the manual way of looking at APIs.
Those kinds of vulnerabilities are the biggest challenge we have in front of us. And thankfully we
have people like Alissa who come after us and find those issues.
Gardner: Alissa, you wrote an e-book recently, The Price of Hubris: The Perils of
Overestimating the Security of Your APIs. Other than the business logic flaws that Rinki
described, what are the biggest risks in the nearly unmitigated use of APIs these days?
Sethi

3. Page 3 of 10
Knight: There’s a library of papers I’ve done on these issues. I feel like every morning, Rinki
wakes up and lies in her room and says, “Oh, my God, another paper from Alissa!” So, yes,
there’s a real struggle around API security.
What was interesting and what I loved about the Hubris paper was it allowed me for the first
time to take all my vulnerability research across industries -- automotive, healthcare, financial
services, fintech, and crypto currency exchanges – and put them into a single paper. It’s a
compendium of all my API exploits that shows this is a ubiquitous problem across many
industries.
It’s not just a Twitter problem or a
whatever-bank problem. It’s an everyone
problem. Much to Rinki’s point, APIs have
pretty much become the plumbing system
for everything in our world today. They
affect life and safety. That’s what attracts me as a vulnerability researcher. It’s like George
Clooney’s movie, The Peacemaker, where the lead character didn’t care about the terrorist who
wants 1,000 nuclear weapons. He cared about the terrorist who just wants one.
For me, I don’t care about the hacker who wants to deface websites or steal my data. I care
about the hacker who wants to go after my APIs -- because that could mean taking remote
control of the car that my family is in or hacking healthcare APIs and stealing my patient
records. If your debit card was compromised, Wells Fargo can send you a new one. They can’t
send you a new patient history.
APIs are the foundational plumbing for everything in our lives today. So, rightfully so, they are
attracting a lot of attention -- by both black hats and white hats.
Gardner: Why are APIs such a different beast when it comes to these damaging security risks?
Learn More
About Traceable AI.
Knight: Humans tend to gravitate toward what we know. With APIs, they speak HTTP. So, the
security engineers immediately say, “Oh, well, it speaks the HTTP protocol so let’s secure it like
a web server.”
And you can’t do that because when you do that, and Rinki addressed this, you’re securing it
with legacy security, with web application firewalls (WAFs). These use rules-based languages,
which is why we have gotten rid of the old Snort signature base, if you remember that, if you’re
old enough to remember Snort.
Those days of intrusion detection system signatures, and updating for antivirus and every new
variant of the Code Red worm that came out, is why we’ve moved on to using machine learning
(ML). We’ve evolved in these other security areas, and we need to evolve in API security, too.
As I said, we tend to gravitate toward the things we know and secure APIs like a web server
because, we think, it’s using the same protocol as a web server. But it’s so much more. The
types of attacks that hackers are using -- that I use -- are the most prevalent, as Rinki said,
logic-based attacks.
APIs have pretty much become the
plumbing system for everything in our
world today. They affect life and safety.

4. Page 4 of 10
I’m logged in as Alissa, but I’m requesting Rinki’s patient records. A WAF isn’t going to
understand that. A WAF is going to look for things like SQL injection or cross-site scripting, for
patterns in the payloads. It’s not going to know the difference between who Rinki is and who I
am. There’s no context in WAF security -- and that’s what we need. We need to focus more on
context in security.
Gardner: Rinki, looking for just patterns, using older generations of tools, doesn’t cut it. Is there
something intrinsic about APIs whereby we need to deploy more than brute labor and manual
interceding into what’s going on?
Humans need tools to evolve API culture
Sethi: Yes, there are a lot of things to do from an automation perspective. Things like
input/output content validation, looking at patterns and schema, and developing rules around
that, as well as making sure you have threat detection tooling. There’s a lot you can do, but a lot
of times you’re also dealing with partner APIs and how your APIs interface with them. A good
human check still needs to happen.
Now, there are new products coming out to help with these scenarios. But, again, it’s very early.
There are a lot of false positives with them. There’s a lot of tooling that will help you capture
some 80 percent, but you still need a human take a look and see if things are working.
What’s more, you have the issue of shadow APIs, or APIs that are old and that you forgot about
because you no longer use them. Those can create security risks as well. So, it goes beyond
just the tooling. There are other components needed for a full-blown API security program.
Gardner: It seems to me there needs to be a cultural adaptation to understand the API threat.
Do organizations need to think or behave differently when it comes to the lifecycle of APIs?
Knight: Yes. The interesting thing -- because I’m so bored and I’m always trying to find
something to do -- I’m also the CISO for a bank. And one of the things I ran into was what you
mentioned with culture, and a culture shift needed within DevOps.
I ran into developers spawning, developing, and deploying new APIs -- and then determining the
cloud environment they should use to secure that. That’s a DevOps concern and an IT concern.
And because they’re looking at it through a DevOps lens, I needed to educate them from a
culture perspective. “Yes, you have the capability with your administrative access to deploy new
APIs, but it is not your decision on how to secure them.”
Instead, we need to move toward a mindset of a
DevSecOps culture where, yes, you want to get the
APIs up and running quickly, but security needs to
be a part of that once it’s deployed into development
-- not production -- but development. Then my team
can go in there and hack it, penetration test it, and
secure it properly -- before it’s deployed into
production.
We need to move toward a
mindset of a DevSecOps culture …
you want to get the APIs up and
running quickly, but security needs
to be a part of that once its
deployed into development.

5. Page 5 of 10
What’s still happening is these DevOps teams are saying, “Look, look, we need to go, we need
to rush, we need to deploy.” And they’re in there with administrative access to the cloud
services provider. They have privileges to pick Microsoft Azure or Amazon clouds and just
launch an API gateway with security features, and yet not understand that it’s the wrong tool for
the job.
If all you have is a hammer, everything looks like a nail. So, it requires a culture change. It is
certainly that. Historically, there’s always been an adversarial relationship between security and
developers. And it’s part of my job -- taking off my hacker hat and putting on my executive hat
as the CISO – to change that mindset. It’s not an us versus them equation. We’re all on the
same team. It’s just that security needs to be woven into the software development lifecycle. It
needs to shift left and shield right.
Gardner: Rinki, any thoughts about making the culture of security more amenable to
developers?
Learn More
About Traceable AI.
Sethi: I couldn’t agree more with what Alissa said. It’s where I found my passion early in my
security journey. I’m a developer by trade, and I’m able to relate to developers. You can’t just sit
there and train them on security, do one-day training, and expect things to change.
It has to be about making their lives easier to some degree, so they don’t need to worry about
things, and the tooling is training them in the process. And then a shared sense of responsibility
has to be there. And that's not going to come because security just says it’s important. You
have got to show them the impact of a security breach or of bugs being written in their code --
and what that can then end with.
And that happens by showing them how you hack an application or hack an API and what
happens when you’re not developing these things in a secure manner. And so, bringing that
kind of data when it’s relevant to them, those are some bits you can use to change the culture
and drive a cohesive culture with security in the development team. They can start to become
champions of security as well.
Knight: I agree, and I’ll add one more thought to that. I
don’t think developers want to write insecure code. And
I’m not a developer, so I couldn’t speak directly to that.
But I’m sure nobody wants to do a bad job or wants to
be the reason you end up on the nightly news for a
security breach.
I think developers generally want to be better and do better, and not do things like hard-code
usernames and passwords in a mobile app. But at the end of the day, the onus is on the
organization to speak to developers, and said, “Hey, look. We have the annual security
awareness training that all companies need to take about phishing and stuff like that,” but then
no one sends them to secure code training.
Nobody wants to do a bad
job or wants to be the reason
you end up on the nightly
news for a security breach.

6. Page 6 of 10
How is that not happening? If an organization is writing code, the organization should be
sending its developers to a separate secure code training. And that needs to happen in addition
to the annual security awareness training.
Gardner: And Rinki, do you feel that the risk and the compliance folks should be more
concerned about APIs or is this going to fall on the shoulders of the CISO?
Banking on secure APIs
Sethi: A lot of times, risk and compliance falls under the CISO and I think Alissa said they don’t
get into it. The regulators are not necessarily going to get into the minutia and the details of
each and every API, but they may mandate that you need some kind of security program
around that.
As we all know, that’s only one aspect of security. But I think it’s starting to come up in
discussions -- especially in the banking world. They’re leading the way as to what others should
expect around this. What I’m hearing from vendors that are supporting API security is that it’s
easier to go to a bank and drive these programs because they already have a culture of
security. With other companies, it’s starting to come now. It’s a little bit more chaotic around how
to bring these teams involved with APIs together so that they can build good security.
Knight: If you think about it, 20 years ago, back when both Rinki and I got into security, it was a
different story. The motives for hackers were website defacement and getting your name on all
those defacements. That was the point of hacking.
Now, it’s all about monetizing the data you can
steal. You don’t go digging for gold in just any
random hole. You try and find a gold mine, right?
Data is the same. Data is worth more than …
Bitcoin. Maybe more than oil. You go to a gold
mine to find gold, right? That means you go to
APIs to find data. Hackers know that if they are
going to steal and ransom a company, and double dip, and then lock and leak -- so leak the
data and encrypt it -- you go where the gold is, and that’s the APIs.
I think there’s going to be an exodus where hackers start shifting their focus to APIs. Knowing
that more hackers are moving in this direction, I need to learn JSON, I need to know what the
hell that is and not be scared off by it anymore, because that’s where the data is. I need to
understand how to hack APIs.
Just because someone’s a hacker doesn’t mean they know how to hack APIs. I know a lot of
hackers that freak out when they see JSON. So, it’s a certain type of hacker. Hackers need to
take their craft -- either a white hat or black hat -- and develop that craft to focus on how to hack
APIs.
The winds are changing and it’s going toward APIs because Twitter isn’t a monolithic application
just like Amazon.com isn’t. It’s not one big app running on one big web server. It’s a bunch of
Data is worth more than Bitcoin.
Maybe more than oil. … You go to a
gold mine to find gold, right? That
means you go to APIs to find data.

7. Page 7 of 10
distributed containers, microservices, and APIs. And hackers are going to learn how to hack
those APIs because that’s where the data is.
Gardner: What do organizations then need to do to find out whether they’re behind that 8-ball?
Is this still a case where people don’t know how vulnerable they are?
Identification, please
Sethi: Yes, I think identification is essential. If you’re kicking this off, at least make the case for
a top priority to identify what your API environment looks like. What do you have that’s currently
being used? What older versions that are not used but are still around and may be creating
risks? Are there shadow APIs?
Finding out what the environment looks like is the first step. Then go through those APIs to see
how they work. What do they do for you? What are the high-risk ones that you want to take a
look at and say, “We need a program around this.” Identification is the first step, and then
building a program around that.
You may also want to identify what teams you need on board because as you’re identifying
what’s already existing, if there’s things you need to do to change around to how developers are
working with APIs, that’s another step you want to look at. So, it’s about building a cohesive
program around building a culture. How do you identify what’s out there? How do you change
how work is being done so that it’s more secure?
Learn More
About Traceable AI.
Knight: As a CISO, I’m quick to buy the coolest new things, the shiny new toys. My
recommendation is that we as security leaders and decision-makers need to take a step back
and go back to the old, fine art of defining our requirements first.
Creating a functional requirements document on what it is we need from that API threat
management solution before we go out there shopping, right? Know what we need versus
buying something and looking at a vendor and saying, “Oh you’ve got that. Yeah, that could be
good. I could use that. Oh, you’ve got that feature? Oh, I could use that.”
Understand what your requirements are. Then, most importantly, you can’t protect what you
don’t know you have. So, does your tool have the capability to catalog APIs and find out what
your attack surface really is versus what you think it is? What kind of data are those APIs
serving? Maybe we don’t need to start by focusing on protecting every single API, but I sure as
hell want to know which APIs use or serve personally identifiable information (PII), or payment
card industry (PCI) data, and all of those that are serving regulated data.
So where do I need to focus my attention out of the 6,000 APIs I may have? What are the ones I
need to care about the most because I know I can’t protect my entire operating area -- but
maybe I can focus on the ones I need to care about the most. And then the other stuff will come
in there.

8. Page 8 of 10
The number one vulnerability, if you look at the Hubris whitepaper, that’s systemic across all
APIs is authorization vulnerabilities. Developers are authenticating a request but not authorizing
them. Yes, the API threat management solution should be able to detect that and prevent it, but
what about going back to the developers and saying, “Fix this.”
Let’s not just put all the onus and responsibility on the security control. Let’s go to the
developers and say, “Here, our API threat management solution is blocking this stuff because
it’s exploitable. You need to write better code, and this is how.” And so, yeah, I think it’s an all-
hands-on-deck, it’s an-everyone issue.
Gardner: Because the use of APIs has exploded, because we have the API economy, it seems
to me that this ability to know your API posture is the gift that keeps giving. Not only can you
start to mitigate your security and risk, but you’re going to get a better sense of how you’re
operating digitally and how your digital services can improve.
Rinki, even though better security is the low-lying fruit from gaining a better understanding of
your APIs, can you also then do many other very important and beneficial things?
CISO’s need good relationships
Sethi: Absolutely. If you think about security upfront in any aspect, not just APIs, but any
aspect of a product, you’re going to think about innovative ways to solve for the consumer
around security and privacy features. That gives you a competitive advantage.
You see this time and time again when products are released. If they have issues from security
or privacy, they may have been able to threat model that in advance and say, “Hey, you might
want to think about these things as an outcome of the consumer experience. They may feel like
this is violating their security or privacy. These are things that they may have in mind and expect
from the product.”
And, so, the earlier you have security and privacy involved, the better you’re going to deliver the
best outcomes for the consumer.
Knight: Yes, and Dana, I consider it fundamental to our role as a CISO to be a human LinkedIn.
You should form a partnership and relationship with your chief technology officer (CTO), and
have that partnership with infrastructure and operations, too.
APIs are like this weird middle ground between the
CISO’s office and the CTO’s office because it’s
infrastructure, operations, and security. And that’s
probably not too different from other assets in the
environment. APIs need a shared responsibility
model. One of the first things I learned from being a
CISO was, “Wow, I’m in the business of
relationships. I’m in the business of forming a
relationship with my chief fraud officer, my CTO,
and the human resources officer.
APIs are like this weird middle
ground between the CISO’s office
and the CTO’s office because it’s
infrastructure, operations, and
security. And that’s probably not
too different from other assets in
the environment.

9. Page 9 of 10
All of these things are relationship-building in order to weave security into the culture of the
enterprise, and, I think, in 2021 we all know that by now.
Gardner: APIs have become the glue, the currency, and a common thread across digital
services. What I just heard was that the CISO is the common denominator and thread among
the different silos and cultures that will ultimately be able to impact how well you do and how
well you protect your APIs. Are CISOs ready, Rinki?
Sethi: I wouldn’t say that they aren’t. Any CISO today is exposed to this. The proof is around,
look at how many vendors are out there solving for API security now, right? There’s hundreds
and they’re all doing well.
It’s because CISOs have defined that there’s a problem that we need to go and solve it. It’s a
multilayered issue, and that’s why there’s so much innovation happening right now. And we’re
not just solving for typical issues in your infrastructure, but also how you look at content
validation? How are you looking at those business logic flaws? How are you looking at
monitoring? Even how are you looking at identifying APIs?
You don’t know what you don’t know, but how do you start finding out what’s in your
environment? There’s so much innovation happening. All CISOs are talking about this, thinking
about this, and it’s a challenge. I do think CISOs are the common denominator in how we bring
these different teams together to prioritize this.
Learn More
About Traceable AI.
Knight: I think you hit the nail on the head, Dana. CISOs are the connective tissue in an
organization. We even have a seat on the boards of directors. We have a seat at the big kids’
table now, along with the CEO, and the heads of the different departments in the company.
And I don’t think the API security solutions were all created equal. I just recently had the
pleasure of being invited by Gartner to present to all their analysts on the state of the API
security market. And all these API security vendors have a different approach to API security,
and none of them are wrong. They’re all great approaches. Some are passive, some are in-line,
some import the swagger file and compare the back-end API to your Open API specification.
Some are proxies.
There are all these different approaches because the attack surface for APIs is so big and there
are so many things you need to think about. So, there are many ways to do it. But I don’t think
they are created equal. There’s a lot of vendors out there. There’s lot of options, which is why
you need to first figure out what you require.
What is the back-end language? What are you programming in? Does your solution shim into
the application? If so, you need to make sure the API security solution supports that language,
that sort of thing. All these things you need to think about as a security decision-maker. We as
CISOs sometimes go out there and look at product options and take the features of the product
as our requirements. We need to first look at our requirements -- and then go shopping.

10. Page 10 of 10
Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored
BriefingsDirect discussion on making the most of APIs by better knowing and managing them
across their full lifecycles.
And we’ve learned how business-critical API users like Twitter are bringing greater maturity to
their API’s methods and protections, as well as looking to the CISO as the connective tissue
across many different parts of the organization, all of whom need to start getting much more
aware of these risks.
So, a big thank you to our guests, Alissa Knight, recovering hacker and partner at Knight Ink.
Thank you so much, Alissa.
Knight: Thank you.
Gardner: And we’ve also been joined by Rinki Sethi, Vice President and CISO at Twitter. Thank
you, Rinki.
Sethi: It was great being here. Thank you.
Gardner: And lastly, a big thank you to our audience for joining this BriefingsDirect API
resiliency discussion. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host
throughout the series of Traceable AI-sponsored BriefingsDirect interviews.
Thanks again for listening. Please pass this along to your business community, and do come
back for our next chapter.
Listen to the podcast. Find it on iTunes. Download the transcript. Sponsor: Traceable AI.
Transcript of a discussion on how Twitter’s CISO makes the most of APIs by better knowing and
managing them across their full lifecycles. Copyright Interarbor Solutions, LLC, 2005-2022. All rights
reserved.
You may also be interested in:
● How Houwzer Speeds Growth and Innovation by Gaining Insights Into APIs Use and Behavior
● How FinTech innovator Razorpay uses open-source tracing to manage fast-changing APIs
● Traceable AI platform builds usage knowledge that detects and thwarts API vulnerabilities
● How to migrate your organization to a more security-minded culture
● How API security provides a killer use case for ML and AI
● Securing APIs demands tracing and machine learning that analyze behaviors to head off attacks
● Rise of APIs brings new security threat vector -- and need for novel defenses
● Learn More About the Technologies and Solutions Behind Traceable.ai.
● Three Threat Vectors Addressed by Zero Trust App Sec