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.
So how did streamlined and cost-efficient home-brokerage-enabler Houwzer construct a resilient application programming interface (API)-based platform as the heart of its services integration engine for buying and selling real estate online?
Listen to the podcast. Find it on iTunes. Read a full transcript or download a copy.
To gain the inside story of how Houwzer makes the most of APIs and protects its user data while preventing vulnerabilities, BriefingsDirect sat down with Greg Phillips, Chief Technology Officer (CTO) at Houwzer. The discussion is moderated by Dana Gardner, Principal Analyst at Interarbor Solutions.
Here are some excerpts:
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 |
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.
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.
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.
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.
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.
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 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
- Web Application Security is Not API Security
No comments:
Post a Comment