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’ protections through greater observability, tracing, and usage analysis.
Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.
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 the latest in API maturity: Please
welcome Rinki
Sethi, Vice President and Chief Information Security Officer (CISO) at Twitter, and Alissa Knight,
recovering hacker and partner at Knight
Ink. The discussion is moderated by Dana Gardner,
Principal Analyst at Interarbor Solutions.
Here are some excerpts:
Gardner: Security researchers at Akamai in their latest state of the internet report detail how cyber criminals 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 such vulnerabilities as the Log4j issue is.
Rinki, how do CISOs such as you at Twitter get the most out of APIs while limiting the risk?
 |
| Sethi |
So, you need a multi-pronged 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?
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.
 |
| Knight |
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?
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.”
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.
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.
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 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.
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.
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?
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.
I'm
a developer by trade, and I'm able to relate to developers. You have to
make their lives easier to some degree, so they don't worry and the
tooling is training them in the process. You have to show them the
impact of a security breach or bugs.
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.
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 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?
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.”
You
can't protect what you don't know you have. Do your tools have the
capability to catalog APIs and find out what the attack surface really
is? What kind of data are those APIs serving? I sure as hell want to
know which APIs are serving PII or PCI data.
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.
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?
CISOs need strong 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.
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.
There's
so much innovation happening. All CISOs are talking about this,
thinking abut this, and it's a challenge. CISOs are the common
denominator in how we bring these different teams together to prioritize
these weaknesses.
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.
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.
Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy. Sponsor: Traceable AI.
You may also be interested in:
- How Traceable AI Protects Against the Log4j / Log4Shell Vulnerabilities
- 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
No comments:
Post a Comment