Great. Well, why don't we go ahead and get started then? Actually, Taylor, would you mind hitting record on your side? And we can, we can also make this available later if you share it with Taylor Wagner. I don't think I have the capability to do record on this one. Let me see. That's it. Let me see if I do. And then I will share it. Unfortunately, I don't. It looks like we can't record this time. So we will fix that for the next one. Okay. Well, I am Dan Khan, the executive director of the cloud native computing foundation. And this is our first try at a more European and Asian friendly hour for the telecom user group. So we have a meeting document that is on the same calendar invite and I'm just going to paste the URL in the chat window. It is a Google Doc. So folks in China are going to need to use a VPN to access it. And then I'm aware that we're also having issues with zoom being blocked by the great firewall and so we're going to need to look at how we need to take a different approach for communications going forward. But our idea is to have two meetings a month going forward, one that's more convenient for us in Europe and the other one that's more convenient for Europe and China. Okay. So for this group. We are aiming to do, I guess the current main initiatives of the tug the telecom user group is to move the CNF test bed forward. So we're just trying to demonstrate real world use cases of cloud native network functions. And then we're also looking at a couple of white papers around usage of telecoms uses of CNF in telecoms. I'd love to shed through where we stand on those. And then maybe. And so I would ask if you're on the call to please add in your name under the attendees. And then I think I would ask Taylor to kick off and maybe do a review of the CNF test bed. And then we could talk through where we stand with other work. The other big thing that I want to mention is that we do have a face to face meeting coming up amazingly in just one more week in Antwerp. So we will be there Monday morning, 1045 am the day before the open networking summit starts. So I am looking forward to getting to see many of you in person, and to be able to engage directly there. So let me go ahead and hand it off to Taylor, I think to start with, and then we can go through some of the other actions here. Thanks, Tim. And I guess I'll drop a couple of links in here. So let's see. Probably easiest to start with the roadmap. Maybe ties in with the review a little bit. I didn't have the review on here. One moment. I can't get the review slide is not coming in. I don't know why but right click. Can you slack it to me? Yeah, I'm trying to, it's just not pasting this slide. There it is. It finally dropped down. Do not like. All right, so and not I can and slack and zoom. So this is a roadmap with a review slide. I just dropped in. Okay. And I can share my screen. That's probably easiest. So a lot of the summer. Excuse me. I have a bit of a cold here. Okay. So a lot of the summer on the scene of test bed has been focused on, I guess you could call it some technical debt and getting folks ready for some restructuring to pull in new use cases. And some new, I guess, technologies. What I don't have here is maybe an overview beyond what Dan has yet so working on that for on us. But what I would think of for folks who are not familiar with seeing up just about this. It's built to be kind of a technology review tool to help folks use and see how emerging technologies for cloud native networking and is going to work for the telecom industry and versus say platforms that are building large reference platforms of a specific technology. So we want people to be able to try out the different things that are being used on kubernetes and there's a lot of options. So a lot of the work during the summer was focused on supporting different pieces. We have these switches that run in and out of the container. And we've been making sure that stuff is working between both the kubernetes and opensack. We did a lot of presentations and gathering feedback on what folks are wanting. Yeah, interrupt for a second to mention. If folks click on your link and open up the presentation for themselves. Every one of these items is a link to the GitHub issue or pull request. And so it's really quite a powerful presentation and if you want to go deeper and see additional context on each of these things. But please go ahead. Yeah. No worries. Yes. These seal jump into either feature or milestone or pull request that these are tied in. There was a lot of work on getting this documentation and code behind that to a point where the people that haven't been working on it can walk in and understand. So those parts that you when you're working on on anything and you have a lot of assumptions on knowing how it works. So we actually worked with the telecom to reproduce the test but they were using some stuff internal and there's some other folks that have also reproduced walking through and following stuff. So we've updated a lot of what was there. And then going forward though, what are what we're looking at so on the use cases. A lot of that was built around what was available at the time, which is more than a year ago when we got started. How are we going to support some of the existing technology. So we kind of just rolled into being Ansible, because there was a lot of pieces that were out of band and not supported in whatever the workload platform Kubernetes opensack. So we wrapped a lot of that in Ansible. On the Kubernetes side, we've been moving towards refactoring a lot of that to be smaller helm based pieces that are composable and reusable. And so that's kind of the move that effort there, and we want to support a different options still for what can be plugged in right now. A lot of the focuses on network service mesh and you'll see those here like this physical gateway neck. We have packet filter there's several in SM use cases that have been in progress and we have a few of those that are working now and we're building on those. This one will probably be one that's going to be showed at open network summit where you have a Kubernetes cluster and the different connections between the CNS cloud native network functions are made with network service mesh, adding additional interfaces and creating the connections between those all the way out to a a a CNF that provides some type of access to a physical interface. So if you think you have some containers running that are connected directly inside pods, and then you want outside, rather than using the Kubernetes default network interface. We created another one and this is with NSM doing that. We had other ways of doing this that were out of band. So this is using NSM to create those endpoints. Taylor, just a question. I think we have been looking at the use case with NSM to try to have external network connectivity to a 3 VPN because quite many operators use the 3 VPNs to separate different sorts of traffic. Is there a use case here that that corresponds to that one? To a VPN connection? Is that to other clusters or? Like a PNF or some some legacy non cloud native VNF. Yeah, so I don't think you should assume that there is NSM on the other side. No, exactly. So the use case I have in mind is where you have a DC gateway where you have a virtual router instance where you terminate a layer 3 VPN. And then you want to connect that virtual router somehow into one of the network service meshes and some of the ports which are served by the given network service mesh. So it's sort of an external connectivity to something that is more like a legacy thing that doesn't have network service mesh in it. So we don't have one exactly like what you're talking about. We, well, that's sorry, I want to click here. We do have some IP sec use cases and what I would say what's been happening up until now is we've been building a lot. We've been creating a lot of the building block type very simplistic use cases so that we could build some more towards what you're talking about. This physical gateway neck. This is a it's allowing routing traffic on a VLAN to an external system. So we have in this one we're sending traffic to a node that's outside and it's on the same VLAN. We have these IP sec and those you could have like an IP sec termination that goes to some outside IP sec system say a system that has a VNF running somewhere else. The other one that we're that's even closer though is what we're targeting in November. And this is something where it could get modified potentially to do something like what you're talking about. This is the Kubernetes and open sec use case. And right now we were looking at a GP tunnel between a open stack and Kubernetes cluster and you would have essentially what you're saying. You're going to have some gateway that's going to terminate or have a tunnel connection between itself and some endpoint and open sec. And then from that it would send traffic to that could be whatever type of VNF that you're wanting and and then a service chain on the Kubernetes side. So we don't have a specific one, but I think we could add that an MSM does have VPN endpoints. So we could potentially do exactly what you're saying. Okay, that sounds very interesting. I think I'll just connect one of our guys who is doing a book on this to these activities to have a look at what's going on and maybe he can contribute. Yeah, we are very much interested. Sorry, go on. Oh, I was just going to ask, could you give us an update? Have you been investigating it or have you made some progress on implementing it so far because I know it is one of the core use cases for NSM and that Ed or Frederick would be happy to help out if you're running into problems with it. Sure. And we've been in constant contact with Frederick and basically we are doing a two phase proof of concept. The first phase has been completed and the second phase is exactly now we know how the system works and we are familiar with it. We want to create some sort of ability to have external connectivity from the network service mesh through some sort of gateway towards, you know, anything legacy that requires VPNs. And well, well, we have a tentative plan of having some something that we can demo by the end of the year. Great. I just want to confirm that you haven't hit any roadblock so far. No, I think it was a hard, it wasn't an easy start. Let's put it like that. But I think we are getting excellent support from Frederick and the NSM team. Yeah, well, let's see. Obviously, we need to get something working and then there is always the characteristics question that we need to verify. But I think so far so good. Okay, you know, for CNCF, we're hosting network service mesh as a sandbox project. And so we're definitely not trying to say, oh, this is completely mature and ready for production, but that it is hopefully very promising. No, and I think I think if functionally we can we can achieve what we want that we could use network service mesh maybe to sort of Let's say get away from the lot of automation that we use infrastructure as a service for. So today for external network connectivity, we need to use infrastructure as a service to set up VLANs and gateways and whatnot. And if we could move away from that using network service mesh for external connectivity, that would be a big thing for us actually. So that's that's our target and we are working on it and I'm happy to bring here as well, you know, the news regarding that one. And also, I think we should really think our activities with what's happening with the CNF test. Yeah, for Thomas, thanks. If you'll reach out to me, we can, what I'd like to do is maybe create a milestone and we can start talking about what's needed. We created a spec board as well so we can chat if we need to that way and create a Google doc and kind of brainstorm on the specifics of the use case. And then see how we can add those and kind of use this as a playground if it would help otherwise I'm just happy to talk about how we've been working at it towards something similar. Yeah, and we are also working on a description of the use case itself so it's easy to grasp what is that what we are trying to achieve so I think we should definitely sync up offline. Sounds good. All right, well, I don't want to take up all the time. Just real quick to finish here. We're planning on adding some other options. I've kind of added them towards more towards the end of the year, although we may get some additional help and these could happen sooner. There's a Dan M demo example set that I thought looked pretty good as a possibility to add in. So this is, I'm just going to bring this up, there's not really any tickets here as we come to it. There's a device plug in SRV demo and looking at this is something potentially we could take and have as part of something we could use as a use case in scene of test bed. Potentially there's something else that's a better fit, but that one's there. And then thinking we'd also like to see what does it look like as NSM. We're also actively working with Intel. We have some people from Intel working in the group and we'll, we've been using different pieces from Intel with what we're doing. But one thing that we haven't had since moving to some of the Kubernetes and container based V switch and other things is using multis as the CPU puller. We have a container experience kid is what they call it where it's basically a small little reference platform where you can deploy everything at once. And we've tested that unpack it. What we've been asked to do is see what parts would be useful to have as components. And we have an idea of maybe a larger use case using some of those. But December will probably have some of the pieces in involved we may even have a NSM with multis and their the Intel device plug in in place ahead of time, but there's some of the ideas. Intel OpenStack is something where we'd like to move away from our current chef based OpenStack. And if we get, I guess, a little bit more help on that then we'll be shifting over ideally that seems to be the desired. We'll move a little further out because we need some assistance on that. And then, in the end of the year towards January. We're going to be working on a GSM gateway type use case we don't really know what exactly that is because we're, if anyone has some feedback on the specific use case I'd like to see with GSM we do have packet has facilities with five G connectivity. And we can set up some type of use case with that so that's a long term goal. And if someone's interested or has some specific use cases for mobile connected, then please reach out. And here's how you can do that. We have issues we also have the CNF Testbed Slack channel. And you can reach out to me as well. I think that's it.  I think I don't know if Frederick's here. And I think I don't know who dropped this in. There is. I know there's like two more iterations of logos so we may need to sense this one. I think these are older ones. I think we may need to pause on that and get the the logos uploaded Dan. I think Fred and Alex and Cheryl and folks have been working on a new set. But I'll hand this over. Thomas, do you want to give any more updates on yours next. Yeah, so I just thought in the white paper there were some very simple chapters that has been lying around in finished state for a while now. So I thought maybe we could give them a kick and approve those simple parts so we can move on and proceed with the more complicated chapters. So if you think that's OK, I'm going to just share the document and show which parts I'm referring to. But first I need to tell you. Thank you. I should be sharing my screen with you and let me know if you see it. Good. So two chapters. One is the definition of the CNF. And I think this came up in one of the comments on the side and was very relevant. So I just sat down together with some of my colleagues. And then I had an online chat with Gage about this. And it's a very simple proposition for a CNF. But let me start with I haven't found any compact definition for a CNF from anywhere else. So if you're aware of this being already defined and I'm more than happy to use the existing established definition. I'm not Tomas and I think the way you're defining it makes sense. Yeah, I mean I try to be as simple as possible here and basically saying that it's a VNF according to the Etsy specs. Not a VNF that fulfills the CNCF cloud native definition. And therefore by joining those two definitions into one, I think we build on already accepted quality things. That was my approach for this. So anyone against this way of defining a CNF or anyone has a better definition. I guess we go for this right? This is a way to get started and then maybe continue to get feedback. It can always be updated. I think so. And I think we need a more beta definition because it's one thing to refer to this high level definition. It's another thing to really qualify. And I remember there were attempts earlier to sort of classify CNF and I don't think that's completely off the table. So I think we need to go in that direction and qualify this, what the CNF is and what the good CNF. But for a start, at least we know what we are talking about. Also, I proposed a target audience for the white paper, which is basically technically minded individuals, architects, influencers and decision makers, both in the service provider telecom operator world, but also in the vendor community. And these people are first and foremost interested in engineering and architecture aspects of cloud native and telecom together. This primary audience has an interest in developing and evaluating CNFs, both from the vendor perspective, driving the development and architecture revolution of the CNFs, but also driving a modernization of a network. So from the service provider's perspective, getting these onboarded and getting into operator networks to generate value and money. Going on, this primary audience is in charge of implementing and evolving a distributed cloud infrastructure in the context of the telecommunications industry. And this is important to signify that there are people who build clouds for these workloads. And this is also a group who should be interested in the things that we are writing down here so that they can build the right cloud infrastructure for cloud native applications. Then, of course, there are those who build these as operators and there are those vendors who build cloud infrastructure and sell it to service providers or provide it as a service. And then finally, the target audience is interested in the overall success of cloud native transformation of telecom. And this includes obtaining the right KPIs when it comes to characteristics, time to market cost of ownership, cost of investment, regulatory and quality requirements. They are interested in ensuring a future compatible end to end architecture that doesn't go out of fashion next year and establishing a maintaining a strategy for handling legacy solutions. So whatever we do here for cloud native needs to interwork with the existing legacy in most cases. So maybe a little bit more fluffy than the CNF definition, but I thought at least this was the target audience I had in mind and of course I very much welcome any comments or any alternative suggestions here. Or if everyone's happy, we just approve this now. And review. Yeah, thank you. So I will change these two. I don't even know because I haven't thought about it. What do we do with parts which are approved, but I guess we'll indicate that somehow. Is Gergé online? Yep. Have you had any conclusions with Peter regarding the SCNF V-mono chapter? No, I got no one's from him on Slack. So let's not close it yet, but if you have any comments and of course I am ready to discuss and I ask him in mail if he wants to add anything else. But from my perspective, this is done. Sure. So I can also ask him in person tomorrow because we meet tomorrow whether he is done and then I guess then we could make this ready and maybe have an approval on the face-to-face meeting next week. Yeah. Sounds excellent. I also saw you added a new chapter on actually quite some others have added chapters here. I saw this chapter with similarities and differences compared to the other cloud native applications. For example, Enterprise and Web and I just read it and I added one suggestion so I think we can still keep this work in progress for a while. Okay. For the next coming weeks. So that was everything from me with regards to the White Paper. One question. Do we have Robbie and or Shukdev in the meeting? Because I think the two chapters which are here with VIP, they are about the same thing. So I believe that both of them are trying to cover CNTT. Yeah, it kind of looks like that. So either Robbie or Shukdev, are you online? No, so I guess we'll handle this offline via comments and maybe Robbie will join for the face-to-face. We probably need to work these out because as you say, these chapters seems to be pointing at the same direction. Yeah. We should be here in town. I don't know if he will join on Monday. Okay, we'll see. But I think we can discuss also this offline. Also, I have Henrik here with me in the same room and he has a suggestion for the White Paper. Yeah, so that was just to maybe establish one view on how we look at the Kubernetes namespaces and how we would like to look at that when it comes to our typical CNFs. So a little bit out of chapter on that and how, for what reason, we want to use it in such a way. So I think there was maybe just one liner there before. So maybe the idea that I maybe start to add a little bit here and then of course people can, I mean, more than happy to have others helping out and defining this chapter as well. But I guess I can start to a little bit right the general idea how we see it and why we want to establish this. You know, if I have a common view of how we would address namespaces, then of course when we deploy our CNFs, it becomes easier to handle them in the same way. Okay, for me. Any other feedback from the community or any other thing that you would like to bring up with regards to the White Paper? All right, so it seems like that's it. Obviously we'll keep adding content and try to bring the already existing parts into the approved state. And I know I have certain items on my backlog that I wanted to contribute to this, so I will get on to that. So maybe we could take a moment and because we did set this up to be an Asian friendly time, I believe we have some folks on the call now from Huawei and Samsung. I'm not sure if we have anyone from Japan, and if they could introduce themselves and ask any questions or say if they would like to get involved, we would encourage that. Would anyone from Asia like to, who's perhaps new from the call, I think we have someone from CMCC and some people from Korea. You just need to hit unmute in Zoom before you can speak. And Tomas, you might want to stop sharing. Yeah, I'm fighting with the controls. I might need to disconnect for a second. Okay, it's okay if you don't want to speak up. One option if you're having problems with your audio connections is that you're welcome to just type in a message into the chat. But we would like to welcome our colleagues from Asia we are very happy to have you involved in this working group, or user group but technically, and I guess I hope there we go. Hi, hi, hi folks. My name is Jian Xiang. And I used to, I used to, so currently I'm active, I'm quite, so currently I got involved in the network service mesh group. And so I've been focusing on that. So from that and also like I joined the CNCF conference, Shanghai, just a couple of months ago. And during that conference I met Tomas and with Nicola and also Taylor. So and then I found somehow interested in trying to find the user case of not only NSM but also trying to find, like say, try to solve this telecom. This telecom scenarios using in cloud native. I mean, idea or concepts. So this is actually my very first meeting joined in this telecom user group. So excited about that and looking forward to more discussions and ideas sharing. Thank you guys. So which company are you with currently I work for Huawei. Great. Well, thank you very much for joining. Oh, thank you. Thanks. And would anyone else from Asia like to speak up. We have, I think, several folks from Korea. Hello. I am from one song from the Samsung. Yes, thank you very much for joining. I'm from Samsung electronics in Seoul. Yeah. Yeah, so thank you for them. Moving time to from the to the. Asian Asian time. Great. So I did want to confirm is this time better. I appreciate that it's still in your evening and not in the middle of the day. It's very good. It's good time to us. Great. Well, thank you for accommodating it. Yeah. So still I'm not familiar with this that walking group. So I, I'm going to be the more accustomed to this, this, this group. Great. Okay. Well, that's, that's excellent. So welcome and thanks very much for joining. Anyone else like to introduce themselves. Yeah, this is Patrick Rokita. Hello everyone. I'm the first time on this call with my colleague, Mohammed El Gamal. We are both from net number, which is a US company East Coast. Mohammed and I, we are, we are located in Europe. So it's a pleasure to us to meet this telco group and participate in evolving the CNCF aspects for telecommunication related deployments. We are at our company transitioning from the VNF to CNF. So this is very helpful to us. And of course the time is excellent for us. Okay. Well, I think our last agenda item was the for Henrik. Did Henrik, were you able to cover the namespaces already or, or did you have more to talk about? And no, I think that was just the introduction. So I mean, I will start to, to add and then of course hope that people will start to, to comment or, or joining defining that. So I think I covered what I wanted to just say. Thank you. Would it also, please go ahead. Yeah, just, just one thing from Thomas. I, I, I know I had a discussion on slack about the license that we should be releasing this document under. And my understanding was that it's creative commons, right? Yes. Thanks for asking. We want to do CC by four dot zero. Okay. But just to be clear, the, the buy is just to give credit to the, the telecom user group, but it's explicitly allowed for commercial use or other kinds of reuse. Do you, do you maybe have some sort of a template blurb or text that can be just pasted into the white paper so that it's clear for everyone who is contributing? I think, I think from say, you just linked to this page. You just say CC by and link there. And, but it's just, it's a very well known license as you had mentioned. And so it does allow you to use it for almost anything. Okay. But then I'll add this to the white paper because I think it's for some of us it's, it's important because, because of legal reasons, it makes it much easier to contribute to this document than if it were under some other license. Oh, I totally agree. Good. Thank you. That was all from me. Yeah. And it's actually one of the nice things about CNCF that all of the projects that we host are required to be licensed under Apache 2.0. And all of the documentation or other kinds of materials that we host need to be under CC by. And then I'll just mention that my favorite example of that is a URL wrong. Fippy. If you, if you click through that link, you can see an example of some of our, some of our CC by material. And we could, at some point, once we've worked all this stuff out, create a nice children's book about 50 tries to listen to some music or something and explain or 50 tries to make a telephone call, how, how the CNF star involved. Okay. Well, if there's not any other new business today, I would hear one other. Yeah, one other question that I got from one of my colleagues is the location of the recorded meetings. Do you have a. Well, yeah, I'm normally they're posted to the YouTube, the CNCF YouTube channel. And you can, that's the link, but you can also just go to CNCF.io and look under newsroom menu. But unfortunately, we don't have, didn't have the permission set up correctly today. And so we weren't able to record this meeting. So this meeting is going to disappear into the ether, but we will have it fixed for the future. Thank you. Okay. And Gerdling, could you give, are you going to have some resources to focus on Dan M in the CNF test bed this fall? Or is that still up in the air? No, yes, I will have and I will have one of the guys in, in Antwerp and I plan to have some meetings with meetings with Taylor to kickstart the. Diver. I'm excited to hear that. So I would love to join those meetings if I could, but I won't. But that's great news. Yeah. Okay. I will, I will keep. Taylor updated on, on Slack. If I have. Sometimes suggestions and stuff like that. Great. Well, let me just confirm that the next phone call for this time is going to be October 21st. And then for the. Other time for the telecom user group. Is a. October 7th. And that's at the, the, the more west coast friendly time. So we're going to keep holding two of these every month. But I, and then I certainly hope that many of you will be able to make the trip to San Diego. For KubeCon cloud native con. We have just published the schedule now. And. I'm pleased to report that our. Friends from. The next foundation networking. Are going to be doing. A keynote there on. A live demonstration of a 5g. Network on the keynote stage using CNS. So I think that that's among other things is going to get a lot of attention for this space. Well, so we'll stop there unless there's any other comments. Okay. Thank you all very much for the time today. And hope to see many of you in Antwerp. Safe travels. Thank you. Thank you. Thank you. Bye. Bye bye. Bye bye.


All right, let's go ahead and get started. First, I'd like to thank everyone who's joining us today. Welcome to today's CNCF webinar, using cloud-native technologies to solve complex application security challenges in Kubernetes deployments. I'm Sheila Sabi, CNCF ambassador and open source program manager at Comcast, and I'll be moderating today's webinar. We'd like to welcome our presenters today, Shreyans Mehta, the co-founder and CTO of Sequence Security. A few housekeeping items before we get started. During the webinar, you're not able to talk as an attendee. We do have a Q&A box at the bottom of your screen. Please feel free to drop your questions in there and we'll get to as many as we can at the end of the webinar. With that, I'll go ahead and hand it over to Shreyans to kick off today's presentation. Thank you. Hi again, my name is Shreyans Mehta and like I was introduced, I'm co-founder and CTO at Sequence Security. Today in the webinar, I'm gonna talk about mostly introducing a new way to do application security, especially focusing on the runtime application security aspect where we have more and more APIs, more applications that are being exposed up through containers in like Kubernetes and microservices environments. So before I kick it off, I just want to briefly talk about our company, Sequence Security. We are a venture-backed startup focusing primarily on application security space. We build an AI-powered security platform which is actually delivered as containers to protect the web, mobile and API-based applications from bot or sometimes called as business logic attacks as well as vulnerability exploits. We are completely built on top of cloud-native components like Kubernetes, Envoy, Prometheus and likes. And we play well with the existing ingress controllers like sidecars like Envoy and Nginx so you don't necessarily need to replace them to use technologies like ours. And for more information about us, you can obviously visit our site, sequenced.ai. So kicking it off, so the world as we see it, there are a lot of publicly-facing applications and you need to expose them publicly for a number of reasons. Primarily for your customer interactions, sometimes you might have mobile applications that need to talk to the actual apps on the backend using mobile APIs. You might have supplier APIs, you might have partner APIs. And the moment you expose them, you are exposed to the bad or malicious actors as well. And these kinds of exposures can lead to attacks like what we call as the business logic abuse attacks. I'm gonna go a little bit more in detail around the attacks themselves. But they are highly automated in nature. These kinds of attacks really go after the business logic or the applications themselves. Typically more about the contract of communication rather than the syntax of the communication. So the content really appears to be legitimate, but they are actually very difficult to detect and block using traditional signature-based technologies. And then there are these traditional attacks, what we call as attacks on vulnerabilities. They are highly targeted. They can be both known attacks or zero to exploits depending on how they are being executed. So that's sort of the high level view of the application attack landscape primarily at the runtime. So let's talk a little bit about how these kinds of attacks are being sort of protected against at least so far. And the traditional world is all about monolithic applications and think of, for our discussion, think of a retail application that has, let's say user management on its side. It has a shopping cart. It has a place for reviews, ratings of the products that you're selling. And all of that is packaged in as a single monolithic application. And you need to protect that, right? And this is the traditional way. And the traditional way is to protect that using what is called as a perimeter defense where you have this application that is scaling up and down using a load balancer.  So the first kind of defense is the defense against vulnerability exploits. And you can think of it as a couple of examples. The first thing that you put in place is the web application firewall. And this web application firewall is doing a couple of things. It is trying to protect the application from more like OVAS type of attacks. It is also needed for compliance in a lot of cases. It is helping you prevent against vulnerability scans, vulnerability scans, think metasploit, think OpenVas, which is trying to expose any vulnerable applications that you might be running. So you might be running something like a vulnerable PHP application or Node.js application. So it's trying to uncover that and that becomes sort of the first phase of the attack. The second phase is really that your graph is also protecting against the actual breaches themselves.  So the job of a web application firewall is to protect against these kinds of attacks that lead to exfiltration or the actual exploit themselves. So you need that. The second part that we spoke about earlier is also about the highly automated attacks that are also called bot attacks. So think of a case, now in this case, this is a retail site that we are talking about. So bad actors, especially competitors, can come in and scrape the entire database of inventory that you might have. They might use that against you in terms of the pricing information that you have and then competitively put prices on their own site. Sometimes we also see competitors scraping content which is really your IP rather than using it maliciously, they might even use that to develop their own content around it based on what you have posted on your site. We also see in the retail site something what is called as inventory lockup. Think about a case where somewhere you have, let's say a thousand items of certain kinds and the malicious actors come in and then they simply add those thousand items in the shopping cart and that inventory is no longer available for you to sell online until this inventory is freed up from the shopping cart itself. Fake likes and fake reviews is another use case where there are thousands and thousands of automated bots can come in and then bump up the ratings of a certain review, good or bad, or try to automatically put in fake reviews on the site. We also see cases around fake account creation where you might have a promotion going on that you get, let's say X number of credits or certain maybe dollars or something like that when you create a new account and the bad actors can end up creating hundreds of thousands of such accounts and drain out those credits that you have available for legitimate users. One other big large use case that we see in the bot space or business logic abuse case is the case of credential stuffing. What we see really is there are billions of username passwords that are available in the black market, especially because of the breaches that have been happening in the past few years. It's either username passwords or email IDs and passwords, so these are stashes of credentials that have been breached through, like, think going back, right? I mean, LinkedIn, Yahoo Breach and most recently, Chipotle and State Farm and things like that. So you get these credentials and obviously these companies have gone ahead and we see the username passwords for these guys to protect the individuals. But the other sites continue to have the same username passwords just because normal human being tends to reuse the same passwords across multiple sites. So what bad actors do is they take advantage of that and they take these stolen credentials and then try it on our retail sites or XYZ retail site and any hit they get is money to these guys. So that's another typical case of a bot attack. And the last protection that you need is protection against application layer DDoS. Now think of it as your monolithic application here. Needs to scale up and down with the kind of traffic that is coming in. But when your traffic is 70, 80, 90% sometimes coming from the synthetic traffic that is being generated by these bots, it may scale up at just the web server level but not necessarily at the application level or the backend database level. And because of that, it leads to unavailability of the application and maybe even sometimes slow down. So in some ways, app DDoS attacks are related to bot attacks as well but it doesn't have a security implication but more of an availability implication. So from your perimeter defense perspective for your monolithic applications, you need all these kinds of defenses in place no matter where your application is running, could be running in your data center, it could be running in a public cloud, wherever that might be. So now coming to the new world of where these monolithic applications are being sort of split up into microservices for various different benefits. I mean, we all understand the limitations of monolithic applications. It's very hard to roll out new updates to these applications. There's so many dependencies between different components that anytime you touch one component, it might lead to sort of breaking some other component and you have to just rely on one application style. Maybe it could be on Java or JS. It's harder for the development teams to sort of develop at a much faster pace that sort of the new world needs. And that's why people are moving towards microservices. And again, you guys are all probably experts in the space, but just to give you an idea how these applications are breaking up. So the original monolithic app that we spoke about can now potentially be split into, let's say a user management microservice that then in turn can potentially talk to the data access microservice. You might have a shopping cart microservice that is separate. You might have a customer reviews and ratings microservice. You might have an inventory management microservice and so on so forth. And all this is being orchestrated through your orchestration platforms like Kubernetes or Istio and so on so forth. Now, you can then individually scale these applications. So let's say you have an update in the new customers because you have a promotion going on. You might just want to individually scale the user management service and not necessarily everything else. You might have a sort of a Thanksgiving sale going on and you might want to scale up the shopping cart and customer review service. So you can sort of take sort of a scalpel-like approach to scale up and down these services rather than scaling up the entire application stack in a monolithic site. So these are sort of the benefits of the microservices based approach rather than a monolithic application. Now, all these services when they were working in a sort of a monolithic environment, they were talking to each other. These components probably still existed but they were talking to each other using function calls or RPCs or something like that. But in the sort of the microservices world, these applications are loosely coupled. They are exposed through APIs and these APIs have sort of a contract sometimes that, okay, only these services can talk to other services. I'm going to talk over TLS and so on and so forth. But they're still prone to the kind of attacks that we spoke about earlier. And let's drill down a little bit more here. So when we move from the monolith world to the microservices world, these are some of the additional challenges that you have to worry about. Number one is because of the newly exposed APIs for these microservices, you have a whole lot more entry points into your environment, right? They might not necessarily be exposed directly but they might be exposed indirectly in the sense that the data access service might not be exposed directly to the outside world but every time you invoke the user management microservice or an inventory management microservices, it might sort of indirectly invoke the data access service or that you could even compromise one of the microservices that are running internally and then abuse the other microservices just because they are exposed eternally. Sometimes these services can even break the contract that okay, I'm only rather than doing a account sort of a check or authentication, I might be doing something else just because somebody compromised some other microservice. So that's one aspect. The second aspect is the scale out aspect where in the monolith world, you were scaling out the entire application stack in one go and you had sized your runtime application security services to maybe for the peak. So let's say in a Thanksgiving time, I need like five gigabits of traffic and that's why my runtime application security stack is actually sized for that. But it does not account for specific services that are scaling up and down because the needs for your application security stack might rely on the individual components and the security that they need rather than sort of a single sort of a brush of, okay, I just need to have this much capacity. So that's, sorry, this is falling down for me. So that's another security challenge that you face where you have individual microservices that are scaling up and down. How do you scale up and down your security services along with it, especially when these services are in some ways disconnected from the microservices themselves. The second big aspect is around keeping up with the sort of the DevOps space, the security keeping up with the DevOps space. So earlier, there was a single monolith application and the security team was actually working with the application team anytime you were rolling update to the application and working closely with them. The whole idea of moving to microservices is the development team, the operations team, they can move with the lightning speed where they can roll out new microservices while coexisting with the older microservice. They could, let's say, they have a new version of the shopping cart application that they want to expose, maybe just to the 10% of the customers first and then sort of scaling up or dialing up to the rest of the community. They might want to phase out the reviews or ratings application and then roll out a new one but they only want to do it based on a region. So new applications are being rolled out at a much faster pace and how does the application security become aware of these applications? So the discovery aspect, the protection aspect, this becomes a challenge from the application security perspective. The third one is, like I said earlier, is earlier you would depend just on sort of one kind of application, secured application stack. Now what microservices allow you to do is you could have a heterogeneous environment, right? Your user management service could be running on a Java stack. Your data access could be on the PHP stack. You might want to move the shopping cart to Node.js stack and so on and so forth. So you see what you have is rather than a single stack and sort of that the security team needs to deal with, now you have a heterogeneous environment and newer and newer stacks keep coming up and the security team, again, needs to worry about these individual services and the kind of protection that they need rather than sort of again a single approach to solve that problem. So that's another big challenge that the security teams need to deal with when you have this heterogeneous environment as opposed to the historical monolith application. And so one last aspect that what these microservices allow you to do is ability to run in multiple clouds. So you could be in the data center, you might have started off with something that like a non-prem of Pivotal or OpenShift and you could be moving to the cloud when some of your microservices are still running on-prem and then some are running in the cloud and the perimeter-based defense approach doesn't really work there because there is no real perimeter in that case. You have all these services that are spread out in different environments and the applications could be moving from on-prem to in the cloud and so on and so forth. So you have to deal with that situation. Now, so what is the new approach that we can actually work with so that we can keep up with the needs of the microservices? So what we're proposing is a new way to do this. So rather than moving, having application security at the perimeter level, the application security needs to move closer to the applications themselves, the microservices that they are actually running. What that means is the app sec at runtime needs to be packaged in as containers and run in the same pods as the applications themselves. So when you are scaling up your application, it just scales up and down with that application. It needs to, the way it can work is it can work with your site card. So when you're in the part, one approach to do that is be the site card itself where it is working when the request comes in, it tries to hit the API. It inspects the application, gives it a thumbs up or thumbs down. If it's a thumbs down, it goes ahead and takes the application out, the request out. And if it's a thumbs up, it lets the application through. But you do need to worry about the existing site card that you might have in place. You might be working with a non-voyer proxy or an engine egg proxy that is, that you rely on for your application delivery. And you don't necessarily need to to rip and replace the existing site cards just because you want to put security in. So these security microservices can actually be injected in conjunction with your existing site cards, either as a site card chain, where the primary site card is hit, it might be your own void, it passes on the request to the upset site card and then sort of upstreams it to the actual application microservice that you're interested in. So it can that way coexist with the existing automation that you have in place orchestration that you have in place. And the existing services that you have in place. So this is what the new runtime application protection needs to look like in the new world, rather than having sort of an application security at the perimeter level, which has no understanding of these microservices themselves. It needs to move closer to the application themselves. That way you are targeting the few limitations of the perimeter defense that we spoke about. As you're scaling up and down these microservices at the individual level, your application security is scaling up and down along with it. As these applications, the new applications are introduced, they can automatically be sort of protected through your orchestration platform like Istio can automatically inject this microservice in the same part. And then you are automatically protected around that. You can take sort of a scalpel like approach for protection. So you might have different platforms that you're talking about like user management running on Java or data services or PHP. Your application, runtime application security, a stack is focused towards protecting just that application rather than just applying all kinds of generic protections for all kinds of services. So you can focus on individual microservices to be protected rather than sort of a generic approach at the ingress level or at the perimeter level. And then the last aspect, the limitation that we spoke about in the monolithic world is sort of as the microservice is transitioning from on-prem to the cloud world or from one cloud to another, the security is actually moving with it. So you don't need to worry about that, okay, did I protect my application in the new environment? It's automatically moving with that setup. But what you also need along with it is a sort of a centralized application security, visibility and control. So you don't want to individually manage these parts, you need a centralized management that can actually discover all these applications that are coming up. You get centralized visibility, how many apps are running, what's being abused, any configuration that you wanna enable, disable for these services. So that's also needs to be delivered as a microservices that is running in your environment rather than going out to the cloud and making all those decisions. So that's sort of the framework that we are presenting. So sort of summing up on some must-haves in the sort of the run-time application protection for microservices, given that you want to empower your developers to roll out new applications at a very fast pace, it needs to be designed to work with the existing applications without asking your developers to make any modifications. It needs to be non-invasive in the sense that you don't want to bundle in sort of no agents or SDK or JavaScript in forcing the developers to bundle in these SDKs or JavaScript rather than it needs to automatically come up when the applications are coming up as microservices. So it needs rather than being sort of bolt-on from the outside as a parameter defense, it needs to be a microservices-based protection to protect other microservices so that it can scale up and down and have all the benefits that we spoke about earlier. It needs to coexist and not necessarily replace your existing in-risk controllers and sidecars so that it needs to play well in that setup. And it needs to be a single pane of glass for all your microservices so that you have one place to manage visibility and all those things rather than individually managing every sort of security service that you're running. That way, your protection moves with the microservice wherever it's actually going. So that's sort of a framework of must-haves that we've defined for the new way of doing application security. So in the end, I just want to talk about the way you should be thinking about sort of the new security stack. Obviously, you need to worry about the infrastructure security where your Kubernetes environment is actually running, the virtual machines are they being patched or not? Does your Kubernetes stack have any vulnerabilities that can be exploited? So you need to keep up with that. The next phase is about the container security itself. So you could have sort of unpatched version of containers that you need to be aware of from compliance perspective, visibility and sort of logging in all those things come into place. Who's talking to who? Is the communication secure or not and so on and so forth. But in the end, you also need to worry about the runtime of the application itself through protections like web applications, firewall, sort of bottom bottom defense and application layer DDoS defense. And rather than having it at the perimeter layer, it's much better to have it closer to the microservice itself and think about that as part of the security stack in the microservices world. So this was more of a introductory sort of webinar. We plan to have sort of a follow up webinar on the actual way of actually how to do it, how do you inject the services. So I look forward to presenting that in the coming weeks or months. I'm gonna wrap it up. Any questions on this, please free to send it over. Awesome. Thank you, Shreyans for a great presentation. We do have some time for some questions. And before we jump into that, I will just wanna add that KubeCon, CloudNativeCon North America is CNCF's flagship event and it will be here before you know it. This year it's being held in San Diego which should still be sunny and lovely in November. This is the time for the community to come together to further education and to advance cloud native computing. So if you'd like to attend, please go to kubecon.io for more info and lock in your ticket before it sells out. So with that, I will go ahead and jump into questions. It looks like we have quite a few. I can read from the top. Shreyans Wahid Malik is asking, is this a micro segmentation or nano segmentation solution or both? So depending on how you look at it, the idea really is, I would think of it as more of a micro segmentation. So as your pods are, the security is built into the pod itself, how you define the pod is really up to you. So if you can take it to the level of nano segmentation if you like. So it really depends on how you are actually designing that solution. Wonderful. And we also have another question from Wahid. Do you integrate with something like Apigee, Axway or Akana? So we currently don't. The idea really is, rather than integrating at the API gateway level, we are sort of more focused on the microservices themselves as they are coming up and down. We have a genetic way to work with the ingress controllers as well. But if that is something like that we spoke about the limitations of integrating at more at the perimeter level that could be API gateway as well. So the approach that we are suggesting is moving it closer to the microservices themselves. Cool. We also have another question from Pradeep Nambiar. It's, wouldn't CAPTCHA block the fake request to some extent? Not really. So what we see is, number one is CAPTCHAs have been broken for a while and especially the sort of Kubernetes or microservices where we're talking more about APIs and APIs can be exposed primarily for your mobile apps or sort of machine to machine communications and CAPTCHAs don't really work there. I mean, there's a lot of information available on our site why CAPTCHAs don't work. Feel free to come there. So it's not a simple answer, but we've seen them broken all the time. All right. Another one from Wahid is, why wouldn't every API call go through API gateway and then I can apply all my security policies at the gateway choke point? So the primary difference here is because of the microservices talking to each other you could have a compromise at one of the microservice level. And that can be used to sort of horizontally move and abuse. So you want protection closer to what is getting abused rather than sort of a perimeter-based approach to solving it. Okay. Another question we have from Joe Hackett. How does your AI technology automate resolution once it detects a bot or DDoS breach? So we have sort of a policy-based approach to doing this. So this kind of technology gives you sort of a intent that what kind of attack is actually going on. So you could see like a scraping activity. You could see something like a fake-like activity. And you can define policies ranging from simply blocking, you could rate limit them or you can even deceive them by sending fake responses. So again, there's a very long answer to it, but you can definitely go to our site and look at how we can actually do it. But we can have policy-based actions to rate limit block, even send signals upstream for your application to decide what you want to do with it. Okay. Another question from Thomas. Should I understand inject as something done in container build time, pod deployment time, or done during runtime? Pod deployment type. So when the pods are deployed, you can inject them as they are coming up. Great. Question from Brian Irwin. Are the individual sidecars in each pod sending telemetry to a sequence controller within the Kubernetes cluster or to a SAS-based service that can span multiple clusters slash clouds? So we have an option for both. It really depends on our customers. We can keep everything within your environment so you don't have to worry about the PII leaving the environment or lots leaving your environment. If your company is opposed to sending any data to a SAS service, if you are interested in SAS service, we support that as well. Very cool. Bhupathi is asking, any open source tools available to run security scanning on Kubernetes clusters? There are a few. I can't think of them on top of my head. This is, so what we presented here primarily is more of a framework. And then you can put together the services like these. You don't necessarily have to use sequence to do that. You can use open source services to do the same. Okay. We have a few more questions from Wahid and Pradeep. So I'll jump into those. Is this solution a sidecar solution or is there an agent per container? It's a sidecar solution. So sidecar or a sidecar helper. So you don't necessarily need us to be the sidecar itself but it can be chained with your existing sidecar. Okay. And is this hybrid solution where if my app moves to private public policy, the policy moves with the app? That's right. Okay. Great. Do you have support for DKS, PKS and NKS? Yes. So basically the kind of approach that we have, PKS, it does work. We've not tried it with MKS and DKS but the approach is genetic enough to be applied anywhere. Okay. Do you quarantine requests or just deny them? We, like I said, it's more of a policy-based approach. We leave it to our customers how they want to deal with it. So we can deny them. We can quarantine them in the sense then put them in sort of like a target or an area where it actually doesn't really hit the actual microservice. We can even send them fake responses. So we have a bunch of options that we can work with. Okay. Another question from Brian Irwin. Is there any difference between running the sequence sidecar versus injecting into existing NGINX sidecar? So it really depends on you. So if you don't have anything, you can use the sequence sidecar. If you, like I said earlier, if you already have NGINX runway sidecar, you can inject into that. It really depends on how your environment is rather than us forcing a particular way of doing things. Okay. And then isn't there risk to let the malicious request already into the pods from the perimeter? And this question I believe is for slide number 13. Okay. So it's sort of a layer defense strategy. I mean, you need to have things that you want to handle at the perimeter layer, things like infrastructure layer leaders and things like that to be handled at the perimeter. But you can't just stop there. The idea really is you would actually protecting the actual microservice. And the protection needs to be closer to that so that it has better context around the request. If you just try to do everything at the perimeter, you lose that context, where it's going, what it's doing. And if there are sort of other internal malicious actors like other compromised microservices that can take advantage of it. Okay. And do you support a deceptive mitigation which can randomize responses as urgent? We do. Yes, we do. So it can be, it's not just a randomized, we can, it can be on a per application basis because every application is different. You can have define your own success, fail criteria. You can define a new account creation criteria. You can respond with different languages. So all those options are available. Okay. And I think we are at our final question. What is the false positive rate that you've seen from the application DDoS layers? Like I said, we have sort of a more of a sort of a short answer is very low false positive rate. And the way you do it is we have a sort of a confidence based approach and policy based actions where you can actually define your own dials. What is the rate that you can be happy with? And beyond that, we can just send the signals upstream to your other applications or fraud system so they can combine our signal with theirs to take action. So that way you can keep the false positives very low yet not necessarily allowing a lot of bad stuff in. Cool. And we have another question from Brian Irwin. Can your solution span into traditional monolithic architectures as well? It does. The way we've designed it is our delivery model is containers. What this allows us to do is in the traditional monolith architectures, we can just deploy ourselves in a sort of off the shelf hardware in a traditional perimeter defense based approach. We work well. And then slowly when you're transitioning into sort of more microservices architectures, we can transition along with them. Great. And it looks like we don't have any more open questions. So thank you, Shrans, for a great presentation. And looks like that's all, looks like we've covered most of the questions, all of them actually. So thank you so much for joining us today. The webinar recording and slides will be online later on today. And we're looking forward to seeing you at future CNCF webinar. Have a wonderful day. Thank you. Yeah, thank you. Thank you for hosting me and the folks that you attended. Thank you very much. Great.


Good afternoon everybody. Thank you for joining us for another weekly edition of Condo Insider, which is put on by Hawaii Council of Community Associations. It's one of our education avenues and that we do, we've been doing it for, I want to say seven or eight years now. So I'm one of your hosts. And today I have with me, I'm really happy and lucky to have with me, Bruce Marveres, who is with Long Bridge Financial. So part of my role as a host is finding, I'm helping to find solutions that could help us in condos. And we all know that one of the big issues that has been the last couple of years are the rising maintenance fees and a lot of it is related to the LSE as we know. So there's about 300 buildings that were impacted by the life safety evaluation that brought in some additional costs. And also with that came the humongous rise in our insurance premiums related to fire sprinklers and also related to the LSE. So, you know, some of us were facing like triple digit increases in our condo master policy insurance, which really wasn't planned for. So there are some condos that were facing special assessments or humongous increases in the maintenance fees. And a lot of the big comments that I always hear from from board of directors is like, but we have a lot of people here on fixed income. So we really are shy to raise maintenance fees, but that's really something that you really can't not raise maintenance fees because of that reason. Because eventually down the road, you're going to get stuck with a special assessment. And to me, that's going to be worse. Because how many people do you know that really have a healthy savings account that they can draw from, you know, even a senior syllable we're living from their monthly check to monthly check. It's just like we live paycheck to paycheck sometimes. No. So I was looking for other ways that we could help and encourage some people to really think financially sound and start planning financially for the future if they're going to age and live out their golden years in their condominium. And this can also apply to single families as well. But our focus today is trying to help ease the burden when it comes to condos. So I want to introduce Bruce Ramirez with Long Bridge Financial. So Bruce, thank you for joining me today. Hello, all right, Leings. Thank you so much for inviting me to your show. And I'm very happy to be here and hopefully provide some insight to regarding the seniors that we're discussing about here today, especially in particular the condo associations that you deal with. And you brought up an interesting point here regarding seniors and rising costs. And we really have a retirement crisis in America these days. You know, when you have, you know, seniors which are living longer, 90% of seniors, 65 and older prefer to stay in their homes as long as possible. Yet only one in three seniors feel like they can adequately provide the necessary features that they need as they age. So here's a real crisis in terms of how do they afford the upkeep of their existing property? How do they make enhancements to it? And when you look what's happened in the last couple of years in terms of the retirement accounts, you know, with this economy, and you mentioned earlier that fixed incomes and what's happened social insecurities are referred to it. This is a double-edged sword is hitting all of the Americans at one time or another. So it's a real crisis. And again, I'm really thankful you brought me on here today. And hopefully we can provide these one or two solutions here for those seniors where there might be an absolute need and desire to improve the quality of lives. Okay, so let's start off talking about the reverse mortgage.  So tell us a little bit about the heck of. So the other word, as you mentioned, reverse mortgage, and basically it's just a lien on your property. What it does, it pays off your existing lien and allows you to no longer have to make a monthly mortgage payment. An average mortgage payment is $1500 a month. That can be a huge savings to a senior. But in a lot of cases, there's also an available line of credit. That's the seniors will have access to as well. So therefore, by limiting that possible monthly mortgage payment, and then having access to a lot of credit that can really supplement their monthly income. So another way looking into what with this market, how it's taken a major dip. Imagine having the sell off assets right now, as the market has been dipping there, and that may not be the most effective way of managing their funds and taking into consideration a line of credit right now is growing out about 8% can be a huge boon to a senior. Imagine paying off a lean of $50,000 and maybe have an access to line of credit of $100,000. And if it doesn't need to be touched at this point, you know, I'd have growth rate around 8%. That means in about nine years, $100,000 line of credit will double to $200,000. If you're a 62 year old senior, and are not needing to touch that until your early 80s, that can be around $400,000. Sit in there and then accessible. Because when you look at it, just look at long term care insurance, only about 13% of seniors have it. The majority of them cannot afford roughly $125,000 in long term care. Most people will realize Medicare doesn't uncover long term care. So let's kind of go that. So basically you have to be 62 years and older. You have to live in that property. So it has to be your primary residence. Six months and a day per year. Right. And it works best when you have a little bit of a mortgage balance. You know, if you have a huge mortgage balance against what your appraised value is going to be, it may not work. Depending on the age and other criteria, right, the loan of value, obviously the older you are, the more that could be loaned to you. Okay. So the higher balance, it's easier to pay that off, you know, higher. So at age 62, maybe about a 30% LTV, you get up higher and upper 80s could hit upwards of around 70, 75% LTV. Okay. And then you brought out about the line of credit. And I think that's where some people may not understand the beauty part of a reverse. If you can put some of those funds into a line of credit versus taking the whole cash out and doing whatever you're going to do with it. But if you put that into a line of credit, it's going to draw interest at the rate of your reverse mortgage. Correct. Okay. It's going to be compounded so it's going to grow and grow tremendously faster if you put it into a bank savings account. The beauty is you can take out, if you want to set up a term payment where each month you want to take out $1,000, you can set it up that way. You want a lifetime payment where you have longevity in your family and everyone lives to 110. You want to set up a lifetime payment to far exceed your life expectancy and the funds will always continue to be paid to you. Or you can sit on it and take a lump sum at your convenience. If you feel like you need to make some improvements to your property, take a vacation, maybe help the grandchildren help with college, take a trip, various options at your discretion. And I think that's where doing the line of credit versus taking out a lump sum is the one that is going to be the most advantageous to any senior, especially when they're on a fixed income, that could be their emergency money. Yes. You know, and we also have to remember and remind our audience that you may not have a mortgage payment, but you're still responsible for property taxes and insurance. And upkeep of your property. Upkeep of your property, very important as well, too. Right. No difference in a forward transaction, forward loan, property tax. Right. And the one thing about a reverse that I noticed is, is if you don't make your property taxes and insurance payments, I mean, they can call the loan due. Unlike a forward or a regular mortgage, but on a reverse mortgage, the lender, if you don't make those payments, they can call that loan due so that that's a big kind of worms. So you're telling me, let me ask you this in the forward world, which I've never been a part of. What happens if you don't pay your property taxes and insurance there, what we're telling you? In the for the insurance, they give notice to the borrower that they don't have insurance. So they give them time to provide proof of insurance. If they don't get that within that timeline, then the lender can do forced place insurance, forced place insurance only covers the lender. It does not cover like the contents of the house or anything like that. It's only going to protect the lender on the mortgage. You know, when it comes to property taxes here, we're kind of unique. Not like other states where they really are pretty aggressive. If you, if you are late on your property taxes, I mean, I've known some people that were like years late and still not a whole lot of activity happened. They're pretty much they would just pay something, you know, but still that can create that lender to call that more reverse mortgage due, you know. Or speak out those issues there too. Yeah. So you got to think about your, if you are on average eliminating a 1500 hour month mortgage payment, funds really should be there to pay the property taxes and insurance if you're making them prior. And you can also set up an impound account when you get the reverse mortgage where actual funds are actually holding your line of credit. They also crew interest at the same rate as what your line of credit does. Therefore, you have more funds in there to cover your property taxes and insurance on your behalf. So borrower can actually request that and therefore they don't have to worry about that anymore. Yeah. And the one thing too that I know with the companies I've been with before, one of the rules of thumbs that we have when it comes to reverse is to make sure your siblings, your children are aware of this reverse. And I know that was one of the biggest complaints up to the federal government is when the seniors had passed, the parents, the kids did not know that they had parents have a reverse mortgage. So essentially they thought they were going to get something clear and clear. So they're surprised to have this big debt and what they're going to do with, you know. I'm surprised how many seniors did not want their kids to be involved whatsoever. Okay. And they're financial affairs. And that happens quite a bit. Then there are plenty of times where you do have the kids which are heavily involved and trying to do the right thing by their parents as well too. And therefore should be brought into the loop with the communication. So it's an individual basis in terms of which direction that is going to go. Right. Right. But it's always best at least. You really need to do it correctly. It's always good to get a trust attorney involved so that there's, you know, that part of it done. Absolutely. We have to see the trust. Right. Okay. So that will be reviewed with our trust attorneys. Absolutely. Okay. And also one other thing too about the light of credit, it will draw, it will gain interest. Right. And it's compounded and the IRS has already made it known that the proceeds from a reverse is cannot be considered income. So you're not having to report that light of credit income or gain as well on your income tax returns. Correct. That's correct because all you're doing is tapping into your existing equity. Yeah. Right. So it's a plus plus if you plan it correctly. If the bars plan it correctly and try to take advantage or put into practice what is available out there to help them age friendly, age healthy, healthy, and age with like a couple seniors that they said, I don't want no stress as I grow old. Sure. That's why it should be part of your financial strategy. Okay. The time to really think about getting reverse is when you don't need it. And to your point, because of the growth of line of credit, you have it available for rainy day. For example, when you have sequential risk, what's happened to a lot of people's investments. The last thing you want to be doing selling off the assets and therefore you're losing the financial, you know, the money coming out monthly basis. And therefore on the down years, being able to access, of course, shows a line of credit to supplement your income until your assets start performing better. And the studies have shown that by the end, you know, nearly 85, 90 years of age, there's typically a lot more available in your assets by using that combined strategy. Okay. So we talked, yeah, that's the basic, pretty much the basics of reverse. And usually the most common one is a heck of. But with Longbridge, you have other products that might be even, even suitable because with heck of it has to be if you're in a condo, you have to get that sonado project FHA approved. Or some of us here in Hawaii that could be a challenge because we need an agent company a lot some documentation that sometimes be a challenge is getting that information. So use that product, we can kind of bypass that route. Right. But going back to the hack comes a bit of a situation where the condo association is not FHA approved. Longbridge does work with a third party vendor in terms of trying to get them approved. So we definitely trying to system that standpoint. Okay. If it's a situation where that can't happen, we do have other solutions. And one is called a platinum jumbo product with the situation that property values need to be a minimum of $450,000. And then we have it a limited review process that we can utilize and to go ahead and get a jumbo reverse. Lynn Cage. Who pays for the cost because that's one of the other miss knowlers is I know for the for company we worked with that have a license with. When we were trying to get it FHA approved. The management company had told them oh no but there's a cost to it that the condo has to pay and we're like no, you don't pay it. We're paying that cost that's. So we pay FHA that their cost or whatever it is. And so, you know, we want to kind of make it clear that the board or the condo does not pay for that typically for that FHA costs it does not come out of their pocket. Right. Okay. Because we want to kind of get that out of people's heads because I've heard it repeatedly over the years like oh no you're you've got misinformation in your head. Correct. And that's where it's important to work with a loan officer that's skilled in reverse and to be very aware of that. Yeah. Okay, so what other things can you educate our our our seniors our audience on I mean for condos is your policy the same for townhouses. Because we do have a lot of townhouses here. No, you don't have to go for the same approval when it's a townhouse. It's specific towards the condos. So much easier on the townhouse, which is beneficial. Now in terms of getting back to you had a question there. No. Okay. Getting back to the general product. There's some differences there. There was no mortgage insurance required. Okay. Which which is big with it with the gentleman sitting with a heck of reverse mortgages. There is more regions charge there, which is a protection designed for the borrowers or it keeps the loan non recourse. Meaning they can never owe more on the property than what it appraise or and also think about when when COVID hit for those that had he locks. What happened to them? Got closed. They went away. You know what happened to reverse mortgages. Nothing. We were still doing them. You still had the line of credit growth. That's a protective page that borrows receive due to the mortgage insurance premium. Now for the jumbo product, we actually do not incur a mortgage insurance premium to the borrowers there. Okay. So it's factored into the loan. The loan devalues a little bit less, but we can actually loan up to $4 million with that product for your higher end homes. Okay. We got a very high end condo. Okay. So it was smaller in the fees there and we do have both fixed and line of credit options there as well too. The growth of line of credit is much smaller. It only grows for seven years, but you have 10 years to utilize that line of credit with the heck them. It's indefinite. If you have the funds available on line of credit, whoever forever to tap into it will never go away. This product's been around for about 35 years in our FHA insured. And heck it's been around for, since before 1989, because I know it was signed into law by President Reagan. Yeah, in 88. So the first one actually occurred I think around 1961. But Reagan started making changes to the program in 1988 made it official and actually I think it's 1991, about three years later. So for our audience out there, it's really not something new. It's been around for a long time. So it's, it's gone through it's, it's caught through it's finding whatever, as I want to say Pukas, you know, to get it to the way it is today. So it's not something new. It's, it's tried and true. And if it's been there that long, it's got it's, it's something that has survived and is well deserved and it serves its purpose.  And, you know, it's been around since this, the late 80s. That will actually 60s, you know. So it's, it's been around and they will not take, when you died, they will not take your house. Well, that's the beauty part of the reverse. So the last part has passed, right? Let's address that. If the errors are your kids, they can go ahead and get a new loan on the property. And take it over. They have up to a year, they can either sell the property and take the equity out of there. And they have up to a year to go ahead and do that. And the beautiful thing is, since the loan of values are lower than a typical forward loan, those loans are typically not going upside down when you factor in the home appreciation. So you've got a situation where borrowers taking funds out on a monthly basis and still turn over large inheritance to their kids. It's just that, you know, the parent passes on just for the kids to notify the servicer as soon as they can. And then again, they have six months and they can ask for two, three month extensions have up to a year to go ahead and either sell the property or to get a new loan and then take. So let me ask you this question, you could explain this to our audience. So what happens if the loan balance is say 500,000? But the property is only worth and it only sold for 300,000. So if the market dropped out and they had that loan for really long time and now what's upside down? Well, that goes back to the beauty of the non-request feature of this loan. If that property is appraised for $300,000, the borrowers that they would like or excuse me, the errors that they would like can purchase that property for 95% of the appraised value. So for $285,000 plus any realtor fees associated with that, the difference between that amount and the 500,000 owed is covered by the mortgage insurance. So that one would only qualify under a Hecum, but not your other proprietary. That would qualify for a Hecum, but we have the same built-in benefits with their general product. If it's upside down, they will not owe more than they're appraised. And you know, that to me is the beauty part of a reverse mortgage because we all know in Hawaii, home ownership is just like, is gold.  So if the whole intent is to try to keep the home and the family, and that's one of the things too in creating a trust so that you can determine who's going to be the one or the most responsible one that can potentially buy it out at the end so that they can keep it in that family. And when you look at the numbers, if you're upside down and someone can qualify to buy it out, I mean, it really makes sense to try to keep it in the family as much as you can. Because I did have one scenario where it was two brothers. They didn't want to keep the one brother could qualify with his existing mortgage. She qualified to maintain that debt. And I said, why don't you rent it out? You can rent it out for double of what your mortgage payment will be, you know? Like, oh, your son's 17 years old, that could be his house in a few years. But they ended up selling it. I was kind of disappointed about that. I loved that house because it was in a cul-de-sac. Something else for senior borrowers to consider. I'm worried about the loan amount growing over time, the interest of crewing. Make interest only payments. This is the beauty of the HACM, the HACM Flex. You have the ability to make partial payments. Maybe you want to take a break three months over the holidays because you're spoiling the grandkids. Or maybe you're just like, you can't afford a $1500 a month, but you can handle the 500 monthly in terms of the interest amount. And therefore, that balance is not a crew. So, yep, you can be very strategic in terms of how you utilize this. Yep, actual flexibility, forward loans. You have to make that payment every single month regardless. Okay? With rewards. You have the flexibility with it as necessary, as needed. This is something that I said to one couple. We were sitting on their deck as we were looking out at the beach because they have an OSHA front property. And I've known them for a long time. And they said, and they're very diligent on maintaining their house, making sure everything's taken care of in the upkeep and all of that. And I said, and they're retired now. They've been retired now for six years. And they're aging. They're in their 70s.  You've done everything you're supposed to maintain your house. Now it's time for the house to take care of you. What are you going to say? Yeah. And they sat for a minute. They go, yeah, that's right. I go, you've got this equity, you know, everything's paid off. You've got this equity. You're fairly debt-free, you know, but they just want to live stress-free without having to worry about money, you know. So, and theirs is probably going to be a jumble, but that was their thing. And so that kind of set them into a little bit less of a stress mode, you know. And really, when you think about it that way, you know, you have everybody. Everybody has worked hard to pay their mortgage, to maintain their properties, you know, in their golden years, it's now time for something where someone to take care of them and that potentially could be their house. I agree. I agree. I had this conversation with my father. He's 93 years old this year. Doesn't have a mortgage. Last year he told me, when I pass on you kids and you can get all the money. It's like that. That's your money. I don't care. Do something with it. And once the last time you've seen a verse telling you all, it just doesn't happen. Yeah.  It's like, we're okay. Okay. Yeah. Well, have a better quality of life. Right. Right. Yeah. Yeah. Consider. Yep. Well, we're hitting near the end time. So Bruce, I really would love to have you on another segment where you can do a reverse word purchase, which is another opportunity to, to do a reverse mortgage and to even gain wealth that way. But maybe in the future that we can schedule another segment where I would love to. Yeah. Yeah. It'd be better if you actually convinced my boss to fly me out here to do it in person just like this. I love dryland. Okay. Thank you, Bruce. And again, anybody has any questions, they can always reach out to us and we'll be happy to answer any of your questions. And everybody have a good rest of your week. Good weekend. There is a long weekend coming up. I think. Yeah. Labor day weekend coming up. So be safe out there. It's the weather is kind of really weird. So be safe with the weather and be really, really safe out there. Several catastrophes happening around the world, around the country and even in Hawaii too, with all these fires and things of that nature. So Bruce, I want to really thank you for being on the show with me today. And thank you for your time. Pleasure. Thank you so much. Mahalo.


At Audrey's Pet Supply, they sell everything from dog chow to cat trees, but it's the location that makes it memorable. We produced maybe toys just exclusively for us, so it's the Bulldog and it's the Newbury Street logo. But after almost three years in business on Newbury Street, owner Brittany Banks says the store will have to close its doors. Back in October, she got the unwelcome news from her landlord, Lunea Retail. It was very cut and dry, it was, you know, we appreciate you being our tenant, but at this time we have different plans and we are going to have to raise your rent. Raise the rent they did, a staggering 133 percent. It's crippling, it's devastating, and it's just something that we just couldn't even possibly begin to absorb and keep our doors open. No business can absorb that. Well, one business could, Yogurtland, the frozen yogurt chain. They signed a lease agreement and they're set to move in at the end of March after Audrey's moves out. If this all sounds familiar, that's because this happened before. This building used to house the J. P. Lick's ice cream, but now it's going to a Dutch clothing chain. At first I thought it was crazy, but Trick was paying around $100,000 a year in rent when his landlord demanded he pay three times more. That's an awful lot of ice cream cones to sell to just pay rent. As local businesses leave Newbury Street with them goes a whole lot of money. According to the Institute for Local Self-Reliance, for each $100 spent at locally-owned businesses, 45 goes back into the local economy. Compare that to only $14 for every 100, your typical big chain story invests. The owner lives in Boston, so money stays in Boston. The employees are all Boston people, or when I say Boston, of course, with my business it's a surrounding area too, but you don't get much more local money or locally made money staying local. Linear retail declined our request for an interview, but did send us this statement. As Audrey's landlord, we too are sad to see that they are leaving the Newbury Street area. Unfortunately, Audrey's is like many retail businesses that simply can't afford to operate anywhere on Newbury Street. It became clear Audrey's was either unable or unwilling to pay even half of what other tenants had offered us, but their desirable space. It makes me a little sad. You know, when you walk up and down Newbury Street, it's like no other shopping street I think in the country. It's so unique because you have these old brownstones that have been standing for 200 years that used to be homes and used to be little small businesses. Now all of a sudden these big chains are coming in, they're knocking down buildings or they're bringing these big huge stores, and it just doesn't have this neighborhood feel to me anymore. At the end of the day, local business owners are quick to admit they're a dying species, at least on Newbury Street. I didn't take it personally, that anyone was out to get me, it's just the way it went. I understand landlords have a business to run as well, but really at the end of the day it's really about doing business respectfully in the right way and things of that nature. Bang doesn't quite know what the future will hold for her. Says she's certain about one thing. I know at least Audrey's at 296 Newbury Street cannot be saved. We know that. It has been rented out to a new tenant already, so we cannot stay here. In the back bay, Luke Jones, BuTV.