Showing posts with label Interarbor Solutions. Show all posts
Showing posts with label Interarbor Solutions. Show all posts

Wednesday, January 12, 2022

When it Comes to API Security, Expect the Whole World to Be Testing Your Mettle, Says Twitter 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 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
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.

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.

How to Protect Against 

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
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?

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.

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.

Get the Free Tool to 

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.

Learn More 

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.

How to Protect Against 

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.

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:

Wednesday, December 01, 2021

How Houwzer Speeds Growth and Innovation for Online Real Estate by Gaining Insights into API Use and Behavior


Transcript of a discussion on
how a cloud-based home-brokerage-enabler, Houwzer, constructed a resilient API-based platform as the heart of its services integration engine.

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.

Complexity and security challenges can hobble the growth of financial transactions for private-data-laden, consumer-facing software-as-a-service (SaaS) applications. Add to that the need to deliver user experiences that are simple, intuitive, and personalized -- and you have a thorny thicket of software development challenges.

Stay with us now as we explore how streamlined and cost-efficient home-brokerage-enabler Houwzer constructed a resilient application programming interface (API)-based platform as the heart of its services integration engine for buying and selling real estate online.

To learn how Houwzer makes the most of APIs and protects its user data while preventing vulnerabilities, please welcome Greg Phillips, Chief Technology Officer (CTO) at Houwzer. Welcome, Greg.

Greg Phillips: Thanks, Dana. It’s nice to be here.

Gardner: Greg, what does Houwzer do, and why is an API-intensive architecture core to your platform?

Phillips: We are more than just a real estate brokerage. We’re also a mortgage brokerage and a title agency. The secret sauce for that is our technology platform, which binds those services together and creates a seamless, end-to-end experience for our consumers, whether they are buying or selling a home.

Phillips
Those services are typically fragmented among different companies, which can lead to an often-chaotic transaction. We streamline all of that into a much smoother experience with our salaried agents and a consistent technology platform across the whole transaction. We are rethinking how real estate transactions are done by making it a better experience across the board, inclusive of all those services.

Early on, we decided to build, essentially, a protocol for conducting real estate transactions. There are laws and regulations for how to conduct such transactions in different jurisdictions. Instead of having an unmanageable variety of local rules and regulations -- in one area they’re doing it one way, and in another area doing it another way – we looked for the common elements for doing real estate transactions, mortgages, and for titles.

We’ve built into our system these common elements around real estate transactions. From there, we can localize to the local jurisdictions to provide the end services. But we still have a consistent experience across the country in terms of offering services.

That’s why we began with an API-first architecture. We focused on the protocols and building-blocks of the platform that we offered to our agents, coordinators, and mortgage advisers for their services. Then we layered on the front end, which has a lot more localization and other services. So, we very intentionally thought about it as a protocol for conducting real estate transactions, rather than building an app to manage just specific types of real estate transactions in specific jurisdictions.

Gardner: When say API-first, what do you mean? Was that how you constructed your internal platform? How you deliver the services? Was it also for the third-party and internal integration points? All of the above?

Real estate transactions gain flexibility

Phillips: All of the above, yes. We wanted to build an API core that was flexible enough to support lots of variants within different types of real estate transactions. We’re already in seven states. And we’re still pretty early in our journey. We’re going to be adding more states and jurisdictions.

We wanted to build an API core that was flexible enough to support lots of variants within different types of real estate transactions. ... We put a lot of thought into our data model and our API platform.

So, we knew from the get-go that was our direction. We put a lot of thought into our data model and our API platform, such that we wouldn’t have to rewrite or break up the APIs every time we entered a new jurisdiction. We wanted a flexible underlying API that we could use to offer a finished product, even though it might look a bit different in Maryland than it does in Pennsylvania, for example.

Gardner: It’s evident that such flexibility, speed of development, and reuse of services are some of the good things about APIs. But are there any downsides? What can detract from that versatility when going API-first?

Phillips: One of the downsides of APIs is once you put it out there into the world, you are supporting that API, for better or worse. Things get built against it. And if you want to change or rethink what you do with that API, you have downstream dependencies reliant on that API.

It’s not like you’re a single code base, where if you want to refactor, you can use your idea to go discover all the things that might break if you change things. With the API model, it’s harder to know exactly who’s out there using it, or what might break if you change the API.

Learn More 

That means there’s a semi-permanence to an API. That’s somewhat unique in the software development realm where things typically move with a lot of flux. We have libraries that are updating all the time, especially in the JavaScript ecosystem. Things are going a mile a minute.

When you deliver an open API, you have to be more thoughtful about what you put out there ahead of time, because it is harder to change, harder to version, and harder to migrate. It’s by definition something you’ve chosen to set in stone, at least for some period of time, so people can build against it.

Our API interacts with third parties. The vast majority of the usage of our API is for our internal front-end application. It’s not like we have tons of different stakeholders on the API. But we need to factor for those third parties and partners. 

Obviously, then, security is another huge undertaking when you put an API out there. This is not an API that is just sitting behind a firewall. This is an API on the Internet for conducting real estate transactions, which are highly sensitive transactions. So, obviously, security is a huge concern when building an API.

Gardner: With so many different parties involved in real estate transactions, to get people to rely on Houwzer as a hub, there needs to be an element of trust. Not just trust about performance, but trust that the activity is going to be safe, and privacy is assured.

What did you do to bring that level of resiliency to your API? How did you troubleshoot your own API to make sure that others would view it favorably?

Keep data safe from start to finish

Phillips: From the very beginning, we’ve been really concerned with security. Even before we had any transactions running through the system -- and we were just in the design phases of the API -- we knew we’re in an industry that’s constantly under attack.

The most common and dangerous thing that happens in the real estate brokerage industry is when some non-public information about a transaction is somehow leaked. There are a lot of criminals out there who can use that information to attempt to exploit our customers. For example, if they find out information about when a closing is supposed to be in the name of the title company, they could pose as an agent of that title company and say, “Hey, for your upcoming closing, the wiring instructions have changed. You actually need to wire ‘here’ instead of ‘there’.”

There are a lot of criminals out there who can use that information to attempt to exploit our customers. It's been a huge problem in the industry. We need to make sure that the information stays private.

We’ve seen brokerages across the country fall victim to that consistently over the past five to 10 years, if not longer. It’s been a huge problem in the industry. So, while an API enables a great user experience by having very streamlined transactions, we need to make sure that the information stays private to only our clients, agents, and coordinators -- and not leak any of that data to the public through the API. That’s been paramount for us.

As far as performance goes, we’ve been fortunate that our business has relatively few high-value transactions. We haven’t had to achieve super-scale yet with our APIs. Our security concerns are a 10, but our scalability concerns, fortunately, are at a two. So far, it’s not open to the masses. It’s more of a premium service for a smaller audience than a free service on the Internet.

Gardner: Given the need for that high level of security, you can’t depend on just the perimeter security tools. You need to look at different ways of anticipating vulnerabilities to head them off.

Phillips: Yes. You must be aware of what you’re putting out into the world. You must assume the worst about who is going to interact with your API, and make sure there is no way for an unauthorized person to gain access to information they’re not privy to.

Since the beginning of building this platform, that kept me up at night. One of the things that ultimately led me to Traceable AI was that I wanted to effectively gain more confidence about how my APIs were being used out in the world. You try to anticipate as much as you can when you’re building it.

You reason: “Okay, who’s going to be calling on this? We don’t want to expose any additional information here. We want to have just the information needed, with no additional information that might leak out. We want really strong access controls on each API request, such as what parameters will be accepted, what will be updated, and what will show in each scenario based on all the different users’ rules.”

Obviously, that’s a lot to keep track of. And you always worry there is some misalignment or misconfiguration that you’re missing somewhere. You want to be able to monitor how the API is getting used -- and, essentially, have an artificial intelligence (AI) capability look for that type of thing in addition to your ability to query for it.

That has been very attractive for us. It’s given us a lot of confidence that, in practice, we are not leaking data. It’s an additional level of validation. Instead of enforcing a perimeter and not letting anybody in, we’re very careful about what we put out there beyond the perimeter. And not only are we careful about what we put out there beyond the perimeter, we’re also monitoring it very closely, which I think is key.

Monitor who’s doing what, where, and when

Gardner: Such monitoring gives you the opportunity to create a baseline of behaviors, so that even for unintended consequences of how people use your API, you have a data record. And you’re doing it at scale because there’s a lot of data involved that humans couldn’t keep up with. Instead, you have machine learning (ML) and AI technologies to bring to bear on that.

What have you learned from that capability to observe and trace to such a high degree?

Phillips: We have discovered a few vulnerabilities that we weren’t aware of. So, there were areas where we were exposing, or potentially exposing, more information than we meant to through a given API endpoint. That was identified and fixed.

Learn More 

We’ve also seen some areas where people have tried to attack us. Even though we don’t have the vulnerability, we’ve seen malicious actors hitting our API, attempting to do a sequel injection, for example, or attempting to read a file on the file system, or to run a command down the system. You can actually see that stuff and observe how they’re doing it without having to parse through raw API requests, which aren’t humanly readable. Those are the first order of insights we’ve gained.

The second order of things we’ve seen are also very interesting. We can look at the API requests segmented by our users and our user roles. That means learning what API requests our clients, agents, and coordinators tend to make. We can now examine how these different stakeholders interact with the API. It has been really interesting to see from a planning perspective.

We can look at the API requests segmented by our users and our user roles. We can now examine how these different stakeholders interact with the API. The API is a living, breathing thing that you can look at and observe.

Even outside of security, it’s been fascinating to see how the system gets used, and the kinds of natural rhythms that occur, such as when is it used during the day. What are these types of things happening versus these other types of things happening?

It’s interesting to see that which would be very hard in the non-human-readable API requests. When you aggregate it and display it in an information display, you can see that stuff. The API is a living, breathing thing that you can look at and observe as it’s out there in the world.

Gardner: Not only as it breathes and lives, but it’s easily updated. So how do you create a feedback loop from what you learn in your observability phase and bring that into the development iteration process?

As the CTO, are you the one that has to cross the chasm between what you can observe in operations and what you can subsequently ameliorate in development?

Security now part of every job

Phillips: Generally, yes. I view that as a key part of my role. Our software engineers are in there looking at it as well, but I hold myself accountable for that function. Also, I try to recruit generalist software engineers who can take security into account, just like with user experience, when they’re building things. 

I find it very hard to build a cohesive and secure product if you are just throwing requirements over the fence to the software engineers from different departments, saying, “Build this.” I think you lose something.

Rather, there has to be a complete understanding in one accountable individual’s mind to deliver the complete product. And that’s not to say those areas of the company shouldn’t have input on what gets built. But the engineers in my mind have to have a deeper understanding. I like to give them as much data as possible to understand what they’re putting out. Then they have that all in their minds when they’re writing the code.

Gardner: Have your developers been receptive to this observability of API behavior data, or do they say, “Well, that’s the security person’s job, not mine”?

Phillips: All of us on the team feel a responsibility for the security of our systems. I think everyone takes that really seriously. I don’t think anyone thinks that it’s “someone else’s” problem. We all know that we all have to watch out for it.

That being said, not everyone is a security expert. Some people may know more or less than others about information security. None of us are dedicated information security professionals. We rely on the inputs from the Traceable AI platform and from what we’re seeing happen to learn about the things that we should be worried about. What are the things that we don’t even know about yet?

It’s about having a culture of learning and having generalists who want to get better at building secure systems and to convey secure APIs. That is increasingly part of the job description for software engineers, to take that into account. That’s especially critical as we see higher value services, like our own, being offered directly on the Internet.

Things are so different now. Years ago, real estate and other financial transactions had some kind of application front end. Then some person would put it all into a mainframe that night and do the financial transactions. Then, the next morning, after it ran on the mainframe, the humans would look at it again. And then they would update your bank account.

Learn More 

Now there’s far more automation. Things happen live via APIs on the Internet. And that’s created much more reason for developers to truly understand the security implications of what they’re building. You simply can’t insert a failsafe as easily, as you start to eliminate process friction, which is what consumers want. There are less natural insertion points for a true dedicated security or dedicated fraud prevention review. You have to do these processes live and in an automated way. Security therefore has to be built into the thing itself.

Gardner: Of course, these transactions come with high urgency for people. This is their home, one of the biggest transactions of their lives. They’re not interested in a wishy-washy API.

How easy was using Traceable AI to bring automation for better security into your organization?

Data delivers better development

Phillips: What I like about the Traceable AI user experience is that you can engage with it at multiple levels. On the most basic level, you log in and it’s pushing out immediate alerts of threats. You can view what has happened since you last logged in, and you can review your bots. It surfaces the most important things right away, which is great.

But then you can also pursue questions about the APIs in production. For example, you can plot how the APIs are being used. They give you great tools to drill down so you can navigate to different ways of aggregating the API usage data and then visualize, as I mentioned before, those usage patterns.

What I like about the Traceable AI user experience is that you can engage with it at multiple levels. It surfaces the most important things right away, which is great. They also give you the tools to drill down so you can navigate to aggregating the API usage data.

You can look at performance as well as security. So even if you’re feeling good about the security, you can determine if latency doesn’t look great, for example. There are a lot of things in there to show where you can go really deep. I don’t think I’ve gotten to the bottom. There’s more to discover, and there’s tons of ways to slice, dice, and look at things. I tend to do that a lot because I’m a power user and like to figure things out. But at the same time, Traceable AI does a great job of using their intelligence to surface the most important things and the most critical security concerns and get those in front of you in the first place.

Gardner: It sounds like these data deliverables provide you an on-ramp to a more analytics-driven approach to not only development -- but for improving the processes around development, too.

Phillips: Yes. I would even extend that into the processes around our business operations, our real estate operations. We’re offering a product through our technology that is ultimately a real estate transaction engine. And we can actually see in the API things that we need to do to make the real-world solution better.

We have three critical stakeholders: the buyer client, the real estate agent, and the transaction coordinator, who makes sure everything goes smoothly. And, using these tools, we can see if the user or coordinator are trying to do something, meaning they’re getting errors. We can see if there is a point in the real estate transaction where we might not have everything included. Maybe the information that was expected to be there is incomplete, and so they are not able to get to the next step of the transaction.

So, you can actually uncover things that are not explicitly in the technology, like a process problem. We need this information ahead of that point in the process, and we don’t always have it. We want to then know what next to build into our protocols for the future.

Gardner: Greg, what are your suggestions for other folks grappling with the API Economy, as some people call it? Any words of wisdom now that you’ve been through an API development and refinement journey?

Take one real estate step at a time

Phillips: Start small and expand. Don’t try to put everything and the kitchen sink out there all at once. We currently represent people selling their home, buying a home, and getting a mortgage, people who need title insurance -- people doing all of those things together all at once.

However, the first transaction through our system was just people listing their homes. We said, “Let’s take on this specific process.” And even at the time that we launched, it was a much less detailed version of the process we have today. It’s really important to release something early that is complete but limited in scope. Scope creep -- of trying to pack in a lot at once -- is what causes security issues. It’s what causes performance issues. It causes usability issues. So, start simple and expand. It’s probably the best piece of advice I have.

Gardner: Assuming you are going to continue to crawl, walk, and run, what comes next for Houwzer? What does the future portend? What other transactions might this protocol approach lend itself to?

Phillips: We thought about all the things needed to consummate a real estate transaction. We have covered three of those. But we are missing one, which is homeowners’ insurance. We consider the core services to purchasing a home as brokerage, mortgage, title, and homeowners’ insurance. So that piece is in the works for us.

Learn More 

Outside of those core pieces, however, there are lots of things people need when they’re buying and selling homes. It could be resources to fix up their current home, resources to move in, guidance around where in the country they should move to as a remote worker. There’s lots of different services to build out to from the core.

We began at the core transactions, and now we can build our way out. That was a very intentional strategy. When you look at Zillow, Redfin, or some of the other real estate technology companies, they began with the portal and then tried to bolt on the services.

We’re trying to build the best technology-enabled real estate services, and then build from that core outward into more of those needed services. Some of the next things in our product road map, for example, are pre-transaction, helping our consumers make more educated decisions about the transactions they’re going to enter into. And we can do that because we have this bullet-proof, secure, battle-tested system for doing it all and great real estate agents that will help guide you through the process.

Gardner: I’m afraid we’ll have to leave it there. You’ve been listening to a sponsored BriefingsDirect discussion on how a streamlined and cost-efficient home brokerage enabler, Houwzer, constructed a resilient core API platform.

And we’ve learned how protecting user data and preventing vulnerabilities across an end-to-end API services approach has allowed Houwzer to deliver user experiences that are simple, intuitive, personalized, and trusted. So, a big thank you to our guest, Greg Phillips, Chief Technology Officer at Houwzer. Thanks so much, Greg.

Phillips: Yes, thank you as well. It’s been a pleasure.

Gardner: And a big thank you as well for our audience for joining this BriefingsDirect API resiliency discussion. I’m Dana Gardner, Principal Analyst at Interarbor Solutions, your host throughout this 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 streamlined and cost-efficient home-brokerage-enabler, Houwzer, constructed a resilient API-based platform as the heart of its services integration engine. Copyright Interarbor Solutions, LLC, 2005-2021. All rights reserved.

You may also be interested in: