Name: Rocket Uniface Security Deep Dive + Ask Us Anything
Uploaded: 2025-10-08T15:30:55.882Z
Duration: 1 h 3 min 20 s
Description: Rocket Uniface Security Deep Dive + Ask Us Anything

Transcript for "Rocket Uniface Security Deep Dive + Ask Us Anything": Alright. I think the gang is all here. Welcome to the q four security in Uniphase plus ask us anything session. My name is Julie Hohman. I am the Uniphase customer solution marketing manager here at Rocket. And I thank you for joining us today. Let's take a quick second. And using the chat feature, let me know where you're you are joining us from. And let's that'll give us our sound check and make sure everyone's here. I'm actually coming to you from the East Coast Of The United States in Greenville, South Carolina. So let's see. We have London, The Netherlands, Switzerland, Germany, San Antonio, Texas, another, Southerner, Gouda, France. Awesome. Looks like we're, all across the globe. I'm gonna give it just another few seconds to let everyone come in, and then we'll get started. Israel, Vienna. Love it. Alright. I'm gonna go ahead and, kick us off here. Alright. So oops. Yeah. So today, we have, the crew with us is Michael Taylor, Jason Huggins, Jorge Nunez, and myself. We also have Greta from our customer marketing team who's in the backstage helping us, and, we're excited for you all to be with us today. So before we get started with our content, I have a couple of announcements announcements for you, but I will quickly turn the reins over to Michael and Jason who will take us through the the current security landscape and trends, and then they'll transition over to, security that is built into Uniphase, things to consider when developing and deploying your apps, and then round us out with security architecture and our road map for security features. And then after we finish, we'll head into our ask us anything q and a session. Feel free to ask, any security related questions or just anything that's on your mind related to Uniphase. And we will gladly try to answer, as many as we can today. Alright. And before we get started, I wanna go over a couple of housekeeping items. So first, this is a brand new webinar platform that we are using today called Goldcast. So bear with us. Give us a little grace. If we have any hiccups, we're all learning. We've practiced several times. And just in case, just, I just wanted you to know that. Next, all attendee lines are muted, and we will be recording today's session, and we'll distribute that to you within a couple days, probably by Friday, by email. And then I'll also post this on the interface forum. You can utilize the q and a feature to ask questions throughout the session. And if you I I see that most of you found the chat. If you go up, there's another tab next to chat that says q and a, and that's where where you will ask the questions. And it will record what questions you ask so that if we're not able to get to everything today, we can follow back up with you later. And then as we get closer to the end of our session today, you'll see a survey pop up on your screen. I think it comes up about five minutes before our end time. We really value your feedback, and we use your feedback to help us shape future webinars. So, please take a minute to fill fill that out for us. Oh, one last thing. Sorry. Let me go back. You can also, select your language for subtitles. If you go to the in this other screenshot that's on the screen, if you go to the top right and click on the little icon with your initials on it, you can select your language there. Alright. Next, I wanna make sure that you're aware that we have some exciting changes coming to the Rocket Software Forum that you'll see take effect in just a couple of weeks. It'll have a new fresh look and feel. It'll give you a lot more bells and whistles than what you're accustomed to over the past few years, and you should be, receiving an email with more detail. And if you already use the forum, you'll be asked to reset your password upon your first login, and this should happen around October 23. And if you're not already a member, I encourage you to join the forum at community.rocketsoftware.com, and then you'll select the interface forum. You'll be asked to register there. And then lastly, last month, we we launched the Uniface connect monthly newsletter. This will be your one stop shop for Uniface product and community updates. Some months will be, you know, a little more robust than others, but I we felt that it was really important to stay in regular contact with you about what we have going on. And if you did not receive the newsletter, I encourage you to head over to the preference center and that's linked on, on this slide, which I'll distribute as well. And you can sign up and register for both product updates, which would be, like, new launches that we do or product releases, and then also marketing updates, which would be, you know, promoting webinars and white papers that we're putting out for Uniphase and any any kind of bad information. And this will subscribe you only for Uniface Communications. And if you have any questions at all, reach out to Uniface at Rocket Software dot com. Alright. And with that, I'm gonna turn the stage over to Michael and Jason. Good afternoon, everyone. Yeah. So this is a new platform, so please, as as Julie was saying, bear with us. We're we're trying to to get through this, and, at the moment, it's seeming pretty good, but we'll we'll see. So, yeah, welcome to this is, this webinar, it's all around security. So we we're going to be going through a bit of the security landscape, and then we're gonna be going into some more of Uniface in general, to get get an overview of of what happens. As Julie saying that we're gonna have a look at, our road map. We with security, though, we're we're not gonna be able to share too much because, you know, security is is keeping things close to our chest. However, you know, we we we can share how we decide what we're gonna do and and what we're gonna be doing. So, yeah, we'll we'll get through that. So first of all, we'll start with, the security landscape and and why is security, why does security matter? So I I think back to when when I first started many, many moons ago, working, in IT. Security was very much part of this the technical domain. Yeah? So we would we would be responsible for making sure the application was secure. However, today, that isn't so much the case. Today, it is very much gone up through the the the management chain, And now we quite often find, very high levels in organizations and and quite often sort of board level that, you know, security is a very hot topic. Yeah. It's it's essential within an organization for the data protection, for customer trust, regulatory compliance, and business continuity. K? So applications, they directly affect the, the reputation of the cup the company and also of the brand. Yeah? And we we we have to, deliver to the end users, good business continuity. K? Application security, it directly reflects the brand reputation and the operational resilience. Security has become, as I say, part of the boardroom. And what they what the the management and the board are looking at primarily is about being secure by design, having secure design principles built into the whole of the development process stack. So what we want to try and achieve as a development team is to be, you know, to be able to proactively address those vulnerable vulnerabilities. We want to be able to reduce risk of exposure to the of of our data and our processes to the to people who are authorized to be there. And we want to build resiliencies into the system so that they are defended automatically against risks. K? And when we look at this when we look at this putting in the secure by design principles, actually, we are not only putting in that resilience, but we're also, putting in a driver for the innovation and growth within an application. So we have to look at the the current landscape of what's happening in in the industry in general. Okay? We are we are seeing a a surge in the attacks on applications. Okay? And they these attacks are becoming more sophisticated on a daily basis. And not only are they becoming more sophisticated, they're also being sponsored at very high levels. You know, big groups of people like anonymous, but also governments as well and states are are are getting involved in trying to get information. Okay? In 02/2024, we saw 16,800,000,000 records were compromised. Yeah? And sixty percent of those breaches involved human error. Forty three percent were due to also application level vulnerabilities. K? The 53% of the breaches, they've linked personal information, and personal information can then be used for stealing identities or for, for convincing people that a bad actor is actually good. Forty three percent, also had well, sorry. Oh, forty three percent, they were to do with the application security and the vulnerabilities within it. So we also see 44% ransomware is now starting to happen. Okay? So ransom ransomware has been around for a little while, but it's a it's a big shift away from the traditional ways of people going in and stealing intellectual property or or customer details or or personal information. You know, it doesn't really matter what the the data is for, for for when it's a ransom. The only thing that matters is that it's important to you, and all of our data is important to us. So are we we we are prepared to go out and spend to, to get our data back, and that's the important thing of of that kind of attack. So these trends, they highlight, you know, the possibilities of financial and reputational risks. Yeah. They they're critical importance of security application development. Yeah. It it's absolutely critical that we we, our application development is, is secure. We are central to operations when we're delivering applications. Yeah. And the applications themselves are both a target and a defense against attack. So what can we do as a developer to protect against this these attacks? K. So there's a lot that we can do. So it's, taking on secure coding practices, is a a very, good step. So making sure code is verified all the way through the development process, that it's not just a single person looking at the code and it it's actually being, treated, you know, in the light of it could be vulnerable. That's an important part of it. We we also need to understand the threat of what we're doing. You know, is there is there a chance of attack from from the features and the and the functionality that we're putting into our applications? And we have to also make sure that we rigorously, test the application. So as as attackers evolve, organizations need to proact be proactive and layer security strategies. One of the biggest areas of of concern is the insider threat. Okay? So as humans, we tend to be, very trusting. So we trust our employees. We trust our our our friends and and the people around us. Okay? However, we cannot guarantee that they are those people. Yeah. The insider threat, they they pose a very complex risk, and very difficult one to diagnose. In the end, we have authorized people to be able to be in our application and being able to use it. I mean, it could be an employee contract, could be partners, etcetera. Yeah? And of these, actors we allow into our system, some of them, hopefully, won't be, or more of them, hopefully, won't be there to attack us, but some are. So there are some malicious people who who want to get the information and be able to, and to be able to sell it or or do harm to to the organization. But the majority is to do with negligence. It's to do with not you know, it's being sort of a victim of phishing or or accidentally mishandling data, you know, exporting something onto a laptop or into a pen drive and then accidentally leaving on a train. Yeah. And then there's another one of compromised. So where credentials have been stolen or in some way acquired. And some and an attacker is getting in based on the the permissions of of someone who is meant to be in the the the system. But all of these people that they have legitimate access, you know, you have given these credentials. You have allowed access into the system. Yeah. And and they also tend to have a familiarity with the system. And because of all this, they're very difficult to be able to to determine. So how do we deal with that? So continuous monitoring, always understanding who's in the system and what they're doing. Stringent access controls, making sure that people people are only able to do with, you know, what they are supposed to be able to do, and also making sure that it's not just a username and password and this two factor authentication going on, to protect, to make sure that just stolen credentials, don't get don't expose us. We we also need to make sure that we train people to make sure that they understand and see the risks which are happening. I know here at Rocket Software, we have regular trainings which we which we attend as well as our our, our emails come through saying that it's from an external source, and we also, get emails which are, pseudo spam or or or spoof, which we have to report, and and that gives us an overall score. Yeah. But also just simple things like having a queue a clear security policy, telling people exactly what is expected and what is not expected from them while using the system is a good way of being able to gain that awareness. What we're actually looking for in the end is a a sort of a multilevel approach to authentication, and it's a shared responsibility. So there is the business. There is the developer. There is also the the person sitting behind, the keyboard. Everybody shares responsibility to make sure that, every you know, everything continues as correct. So spoofing of identities, you know, as I said, the the people are, you know, they they are, victims of of this. Yeah. Giving people information was to be able to do it, to be able to to help themselves is the important thing here. Yeah. So, you know, people fall for the spoofing requests. It happens all the time. We also you know, you you get now as a new thing of people working from home. Is the person that you've hired into your business actually genuine? Yeah. That that's something that happens more and more. So, you know, these are outside of applications. But in the overall security scheme, you know, these are all important things which we have to consider. Yeah. Yeah. The basically, the tech the the tools which they, the the the attackers have is about exploiting trust. You know? As I say, we we are trusting, as humans, we are trusting, and that trust is easily exploitable. And what they're trying to do is just to to be able to bypass traditional controls and be able to get hold of that information. But the consequences are large. Yeah. So financial fraud, data theft, reputational damage, etcetera. So strong identity verifications, as I say, two factor authentication, anti phishing technologies, user education. These are all things which go into helping to make sure that the the the application remains secure and, and, yeah, and the data remains, you know, remains within your your grasp. So when we look at the applications themselves, you know, what are the things which we should be considering to to make sure that we are closing the the standard ways of of a system being attacked. Well, luckily, there's there's a a group called OWASP. They sort they are, a foundational guide for identifying critical security risks in web and desktop applications. So every so often, they they produce a a list of the the top 10 threats. Yeah. And, you know, it it's good to be able to measure what you're doing against these. Yeah. And to find out, whether, you know, you are you you are adequately, dealing with these threats. So, if we look at their top 10, broken access control is a a a strong one, is a top up. Cryptographic failures, making sure that things are, you know, data is encrypted at rest. It's it's encrypted in transport. It's, special items are encrypted generally. You know, making sure our design is secure of our application, and making sure that, you know, any security measures which are within the system are correctly configured. Yeah. There are additional risks, vulnerable components, you know, making sure that what you are deploying, you know, it it's up to date. It doesn't have known vulnerabilities which can, can can leave the application exposed. You know, authentication failures, they should be dealt dealt with properly. They should be logged and should be investigated. Integration integrity failures, you know, logging, logging is is really important. You know, make sure that the system is properly logged so you can understand what's happening within within the system. Yeah. You know, the the causes of this, it tends to be coding practices, and it tends to be, awareness, and, you know, the the the threat modeling, not thinking necessarily about the security as you're as you're going through and, and and developing applications. Desktops have a whole new set on top of it. So, OS hardening, that's that's critical on a on a desktop application. You know, each each individual PC that is running the application and has the application installed is a point where, a vulnerability can encroach. So as I say, OS hardening, making sure all communications are secure, but also, you know, making sure that hard coded secrets are are properly dealt with. Yeah? In the end, the the the client needs to be able to get hold of the server. You need to the these secrets need to be held in a secure way. So in in Uniphase terms, you know, path path scrambler, seeding, and all that kind of stuff is really important. Okay. Again, if we look at how, you know, mitigating the, the risks, secure coding is important. Code reviews, automated testing, and continuous education. These are all the, you know, these are the standard responses about how do you mitigate all of these, the these, these threats. And looking at the the OWASP guidelines, they help you reduce the attack surface of your of your application, and it helps build with that resilience in the application. So if we look at, going forward, the the future of of security. Okay? You know, the regulations which are which are which have been coming out now for for a long time, they will only become stronger. They will only become, more, you know, richer as time goes on. But, you know, what we're trying to do is to, you know, use these regulations as keys for being able to understand, you know, where the threats are and what we can do to mitigate them. Yeah. So we look at things like GDPR, NIST two, which is, critical infrastructure within Europe, DORA around financial institutions, you know, and and OS standards, which, which companies can can attain. They all help us to understand the the threat to within an application and and, you know, give us they tell us how we need to fix it. K? So, you know, with that, it also gives us that stronger data protection, and the the improved operational resilience. We see, the attack services increasing, so people moving into the cloud, gives a a different, different challenges. APIs being exposed, you know, mobile and and, remote working, that gives us extra challenges as well, the things which we have to consider. Security now requires, you know, a shared responsibility. Yeah. As I say, it's not a technical thing anymore. This is something that is from the top of the organization, you know, throughout. Every everywhere needs to be, needs to be working on this. So developers, IT teams, business leaders all need to be behind it in sponsoring, a a good security model within the application. Best practices, zero trust. You know, we are trusting, but we can't be trusting. Not when when data and and, you know, there's so much on on the line. So zero trust is is really important. Everything must be verified. K? And then least privileged is another excellent way of being able to protect us, making sure that only the privileges needed to do your job is something that is is available to the to the user. We also see artificial intelligence. And just like everywhere else, artificial intelligence is, you know, it's it's causing a disruption, both for the good and for the negative. You know, artificial intelligence is finding new ways of being able to, protect applications. However, it is also being used in, to find new attack vectors. So, you know, this is going to be an arms race as we see see continuing. So in the end, applicate you know, when when dealing with security, you know, what we've seen is that, you know, it is possible to protect ourselves, but we have to stay agile. You have to be thinking about, the future and forward thinking. And it's not a one and done. You know, security is something that is gonna be a continuous improvement within applications. So that's the end of my, horror story. And and now, you know, this is where we sort of move on and have a look at, UniFace and how UniFace, helps address some of these, these challenges. K? So what we're gonna do is something that we we haven't tried before. We're gonna be working as a a roundtable. So it's gonna be myself and Jason who are going to be sort of having a conversation around security. But feel feel free. We have a a bunch of subjects which we we've already have on our side, but if there are other things which you are interested in and you would like us to talk about, well, we're absolutely fine with that, or at least Jason is. So, yeah, please ask in your questions and answers, and and we we'll do our best to to to to talk about that. K. So if we look at out of the box security, I'm going to as I've been talking so much already, I'm going to ask Jason to to pick a topic about what he where he finds, you know, some of the inbuilt functionality within UniFace. You know, the things which are the bedrock and the foundations of the UniFace runtime environment. You know, which ones does does does he want to talk about now? Jason. Yeah. Thanks, Mike. And hi, everybody. So as Mike's been talking about, data security and we see the various privacy laws and the potential consequences of the breach, I'm gonna look at the web, and I'm gonna say, yeah, the way we handle security and data transmission on the web, has vastly improved, and much of that is thanks to, the customer base getting feedback on what they'd like to see improved. So a couple of things there. We sort and hash all values, to make sure they're tampered with, that, we can detect that. If we put read only fields out and someone taps with those, again, we detect that automatically. On the data currency side, we've got functionality in there to say, if a record has been modified by somebody else, then, we detect that and can handle that. What I find really important for the web is controlling which data is get gets sent to the browser. Naturally, with data breaches, if too much gets sent out, that's all data that can be scraped, stolen, and misused. But as a developer, when you, construct your components, we will literally only send out the data that you add to the structure. Now you're all used to having entities, say, in a desktop component where all of that data is actually accessible in that component. You can go in a debugger and see everything. On the web, it's slightly different because, literally, we will only send out let's say, if you had a login screen with a username and password and you put those infrastructure, those are the only values that will go back to the forwards. In terms of what happens at the back end, Uniphase does have access to everything, but, again, we make sure we control which data is actually exposed to the front end. I don't know. Back that one back to you, Michael. What do you see in terms of types of threats we see out there and the types of attacks people do? What's something that Uniface does for us that, sort of goes unnoticed but adds massive value? So no pressure there. Okay. So, for me, probably, the the top thing here is gonna be the code injection, side of things. So, you know, one of the the OWASP points is, you know, prevent prevention of injection into an application. An injection is is trying to take some kind of information, put into some kind of input, which is then causes the application to behave in a a nondesigned way. Yeah. So the the the famous one is, you know, putting into a field, you know, close quote, semi colon, drop table employee. Yeah. And that being treated by the, by the the SQL interpreter as being actual valid SQL and dropping the employee table. Obviously, that that would that's a that's a really bad thing. So Uniface, pretty much, well, Uniface throughout, the technology stack uses it uses different ways of being able to to validate and make sure that doesn't happen using standard Uniface functionality. So within the driver, we, we, pass or we parameterize our SQL statements, which we pass through. And then the information that we pass through through the UAW, through the QA query by form, etcetera, is all parameterized. So it is taken as the contents of the field and not as the SQL statement itself. A similar kind of thing happens in the web where the information that is being passed to and from is treated as information, not as code. But, yeah, throughout the UNIFEST stack, you know, start using the standard UNIFEST functionality, the protection against SQL, HTML, JavaScript, CSS injection, you know, that's that's pretty strong within the environment. Obviously, there's there are ways using SQL statement and the u and the where statement that could that can circumvent this. So, you know, everybody has to be, you know, has a shared responsibility. If if information is being, gathered from from an external source, and used in one of those kind of statements, you know, it has to be validated to make sure that it isn't gonna cause that that kind of problem. So for me, that that's a, you know, an underlying big strength in Uniface. Yeah. Sounds good. So Yeah. Jason, I'm gonna just throw it back to you. Yeah. So I'm gonna pick, memory management as safeguarding sensitive information. So putting my hacker cloak on, the ways you attack information, systems is not always through the front door or through the back door. It's just other ways. And a subtle way of, attacking applications is maybe trying to crash that application. And for those that have worked from Linux or even Windows sorry. I'm losing my voice. You can get a core dump. And a core dump is basically a snapshot of everything that's in memory at that time. So you can imagine that if you've got sensitive information in memory, such as your login pass to the database or anything else that someone shouldn't see, if you can crash that application or attach to that application and grab that memory, you're potentially getting access to things, well, you don't want people to see. So, yeah, we can't go into detail about how Uniphase handles this and how it manages it, but, ultimately, we will keep sensitive information in memory for as short as possible and use various techniques to, safeguard that information should that memory get compromised. So, again, something that's just happens automatically. I like my voice. Yeah. I like it. I'm gonna hand back to you, Michael. I don't know why I swear I'm here. Well, thank you. You might want a drink, Jason. Yeah. I suppose the next one for me is the secure development practice. The the encryption sorry. The oh, we've got a question come in from Ingo. I'm just gonna finish this one, and then I'll, I'll I'll pick up on, on, Ingo. So, secured development practices, so generally within Rocket, you know, throughout all of the products which are part of the Rocket family, you know, we we have when we look at our development stacks and and and how we develop software, you know, we we go through a secure development life cycle. Yeah. So, the developers are not allowed to check directly into the the main branch. The, everything that does get merged into our main code line has been through, several reviewers. You know, once it has been checked in, it goes through, you know, robust testing. And if if anything fails and it is thrown out to be to be reworked, you know, we we securely package it. You know, we securely, we run it through, code scans, so things like Polaris, and we run it through third party, utilities like Black Duck to tell us if there's any, vulnerabilities, in the packages which we use to build up Uniface. We cosign everything to make sure that it it's secure, and this all happens before we deliver the the applicate the the the code to you, every two weeks. Yeah. So, you know, I think that the lab does a a very good job of making sure that that that happens. Also, as part of the the development, we we go through a process which we, you know, we we write a proposal about, we have the story of the feature which we want to produce. We create a proposal. And as part of that, there is a a section which we have to fill in, which says, security considerations and risk analysis. Yeah. So this happens for everything that goes through Unifin. So DORA requires encryption of values in use. So the you know, with this kind of thing, if you the amount of information that Uniface applications hold is significant. Running everything through in having everything encrypted is is not you know, generally would would have a a performance of impact on the system. But you are able to still make sure that, using dollar encode, the sensitive data is being encoded and and is is being kept safe within memory. Internally, when we pick up information from assignment files, you know, all of that is held in memory to username and passwords, etcetera. That is that that's all, not in plain text within within the UniFace runtime, and we make sure the information is cleared when it's no longer needed. Okay. So we're we're moving on to the next one, which is secure, considerations when developing applications. Yeah. So How's your voice? My voice is back. Sorry about that. Yeah. So, again, we have a number of topics here. And, actually, Michael already started talking about one of those, which is the encryption and decryption routines. So, yeah, that was something that was added, I think, towards the end of version nine, may yeah. Yeah, version nine. And what you'll see with that, it gives you the ability to, encrypt or decrypt with various standards, whether that's AES, one two eight, two five six, five twelve, and so on, and many of the other industry standards. The other thing is if you just need hash values, for example, so we're working with passwords, then you can hash those values Yeah. With passwords, I hope nobody on this call stores plain text passwords, but also never actually store an encrypted password. And as strange as that may sound, the logic is if you've encrypted something and someone has that decryption key, they can just decrypt all of your passwords and get back to the, the original passwords. So that's a massive risk. What you actually want to do is hash those passwords, which effectively creates a one way checksum, which can't be reverse engineered. And then all you do is when someone enters their password, we generate that hash, compare it to what's in the database. And if they're the same, you know, it's a correct password. If they're different, it's not the, correct password. But the key thing by using a hash for those passwords instead of encryption, it it cannot be reverse engineered. So even if your database gets compromised, you're not then weakening, people's security on other applications because, you know, fortunate fact of life is humans are lazy and we still use far too many of the same passwords across many sites. So it's part of our responsibility to help protect the whole infrastructure of applications out there. What jumps out to you, Michael? So something that I think is is, very underutilized is the slash no debug. Yeah. Creating a a release version of the codes to be able to put out onto into customer sites. You know, the the debugger is able to get, to attach to running applications. It's able to to see the code within components, unless you have the slash node debug there. Obviously, there are times when that you you you want to be able to do it, in which case, you you have a debug build in order to be able to do that. But, you know, generally, I would always recommend the slash node debug. And and now all of the executable code, you know, it is caught up in the slash node debug. So that's global proxy. It's a new thing that's been added fairly recently. Just to jump on that one, Michael, for anyone that's not gonna work with it, when you're talking about slash no debug, I mean, we've got three ways of doing no debug. So do you want to explore those and say which one you're referring to here? So the first one I know of is is when compiling your application. You have the ability to on on the compile, property or compile commands, have the slash no debug. And and that prevents, you know, the the debugger from being able to to show the information. There is a a no debug command which you can put within, within prop code, and that then means that, you know, the the debugger is turned off. And what's the other one? You can do it in the assignment file as well, can't you? Or is that an old thing I'm thinking of? I think that might be an old thing you're thinking of. Yeah. Assignment files are are are, you know, security and assignment files are are great if you're able to lock down the assignment file. But, you know, the settings are are changeable, you know, quite often. So gotta be be careful of what what goes in the assignment file. You know, as if it the slash no debugs and debugging code no debugging code, you know, they're they're they're things which are they they don't change. They're part of your development stack. And and once they they go into deployment, you know, you can then you can't change them. Yeah. Yeah. Yeah. For deployment, I'd always do it at compile time because there's no way of bypassing it then. Yeah. Okay. So the I Hank, vendor fair. Thank you, Hank. Always trust you. There is a dollar load debug, and it is a assignment file switch, for the compiler. Yeah. So it's not a runtime thing. It's a compiler thing. Excellent. There are so many things in Uniface. You learn something every day. Always trusting. What about your next one then, Joyce? Me? I guess, something that isn't used, very often. Let's see. Yeah. Code quality and consistency. Again, I was consultant for, what, thirteen or fourteen years. That's something that didn't really get used a lot. I didn't see it much was the partner and public web. Sorry. Not web. Partner and public modifiers on operations. Ultimately, what these do is say, what can call these? Unless they're public, they can't be called by other things as such. Now at a high level, if you're writing code, you wanna control who who can call that code. By default, everything is public on services and, unit based components. So you should really think about using these modifiers on your code to say, is this actually a method that can be called externally or by other components? You have to look at documentation how these actually work. But if I gave an example, if I've got partner operations, for example, they can be called by other components, but it can't be called directly from the web. If I just set everything to public web, then everything could be called. So, again, just think about what can actually be called. This would be especially important, say, when using SOAP web service calling. Again, ensure that you specify things that are actually public versus those that should be protected. And I would say as well that, you know, even operations in collection and, accounts and, and components, you know, you should think about that modifier. Put public on things which should be being called your external API, and your internal API marked as being partnership. Yeah. I suppose the the last one for me on here is, the TLS profiles. Yep. You know, the one of the the advances that's been happening, in the interface is that the TLS profiles are now, definable outside of the, the components, outside of the code. So if a vulnerability does occur, then it doesn't mean necessarily breaking down when I say vulnerability occurring, I mean, you know, a a compromised encryption routine or or something like that. You know, it doesn't necessarily mean recoding the component or going and breaking up in the code and putting through the whole development stack. You have the ability to define this in in your TLS profile. You know, that that simplifies, the response to to to threats which might be emerging. And, ultimately, that basically allows you to encrypt any network traffic between any of the unit based processes and even to things like, email service for SMTP and things like that. Yep. And email that and stuff. Yeah. Okay. Very useful. Okay. So TLS ties in nicely with sort of the deployment and DevOps side of things. Indeed. You're not seeing that first one, Michael, because I love that one. So pick something else. Okay. So I'm gonna leave the first one to you because I know you love it. So, you speak very passionately and eloquently about that. Yeah. I think just basically, from for me, you know, security configuration. Yeah. That's a that's a a big one. This is normally when you have, you know, it becomes more important the the more open the environment is. You have it if you have an application that is just stored in the server and only very few people get in there, you know, you're a hell of a lot safer than if you are, sort of customer you know, you you have your application installed on on lots of different PCs. So if you do, then you have to make sure that, you know, the OS configuration is correct. You need to make sure that the settings and the files and third party, etcetera, etcetera, you know, you harden the web server. You know, we supply, Tomcat out of the box, and we do that to give us an out of the box development experience. Yeah. However, when deploying an application, really should look at properly, securing the web server. And we supply Tomcat. Tomcat isn't the one which we say you should use in your do your production environment. We support the server version. And then, you know, as long as the web server also supports that server version, you should be able to use it as a front end of of Uniface. But you should go through a process of making sure that it that it's properly hardened. It's not giving away more information than it should be giving away, etcetera, etcetera. Yeah. Application permissions, this is the the least access, way of thinking, you know. Only give people what they are in, need, you know, what they need in order to be able to do their jobs. Yeah. So, Jason? So, yeah, application certification. Basically, I I love this functionality because it just massively increases the security of your solutions. And, ultimately, this just comes down to, well, two things, protecting your database connections because, again, the database is king, that data is king, you need to protect that, but also preventing people from tampering with your code. So if you had a malicious actor, especially with some insider knowledge, they could potentially build a malicious unit based component, deploy it, and that could run and do whatever they want. If you have a certified application, have certified components and bind those to your database parts, it means only things you've actually deployed or your DevOps teams deployed, so they should be the only ones who have the capability of building and deploying the applications. Only those verified applications can be be deployed. If someone tampers with the data paths, tampers with the components, the application will just exit there and then because it knows it's been tampered with. And sounds like a complicated process, but literally, with four command command line statements, your application is just massively secured and somebody at my door. It's massively secured. And if you haven't looked at application certification, just it's a no brainer. Take a look at it and start implementing it. Yeah. So there was a a question came in about, from Jack from Yann, about, is there an easy way of storing the encoded database, path, password, etcetera, in the assignment file? Yeah. Pathscammer is is the way to do that. It it, you know, it's gone through a lot of iterations over the years. So very recently, it's gone through its latest iteration, which also adds a seed onto it as well. So it properly encrypts it in order to be able to to keep it secure. Yeah. Just to add to that, Mike, Ingo's asked about encrypting the logical section. With the, updated new passgram alert, you can pretty much put markers around any sections of the assignment file and encrypt those as well. And something to be aware of is when we say pass scrambler, originally, it was a scrambler. So maybe a little a 64, shift a few things around. It wasn't encryption. But our scrambler now, we shouldn't be naming it to path encryption or something. It is full on AES encryption. So, you're not breaking that in the lifetime of this universe. We've been asked as well if there's a for cert dot exe, it says it's Windows only. Is there, you know, other platforms available? No. Not at the moment. We have been asked about that. That isn't you're not the first person to ask. It is on our we we have an internal list of things to to be working on. It's definitely on there. I put it on there, you know, several months ago as as people have started asking for it. So we we hope to get one out again for for Linux. I think that the reason, why we didn't do Linux at the time is that, you know, the majority of all the the development happens, on Windows. So therefore, having the cert dot exe to generate it and to be able to, to do the archives, you know, made a lot of sense to have them on on Windows. But we recognize that it is something that we need to also do on Linux. I just want to grab one more point on here for people to consider. If you haven't, your uRouter is basically the entry point to your servers, whether it's curriculum aware or desktop, so calling, things like that. That's something not many people are aware of. It's explicit NIC binding. So if you can imagine, you have servers that have got multiple network cards. Each of those is an entry point to your server. Now in deployment terms, you probably don't want one of those NICs to actually be used, at the entry point. Others could be for internal monitoring or whatever. But in terms of someone connected to the new router, it should be controlled, but you should only expose what you need to. And what you'll see with the new router is you can. So you'll see, things like the port net in the, assignment file or you can do it when you install the u router. So u router slash install and then specify it. But what you can do there is basically specify the IP address of the NIC you want to find to and then the new router will only listen via that, network card. So that's one that's often overlooked, but, again, significantly increase increases your security because you're expected things to come through one area. And if someone comes through another card, that's a security risk. So, again, one to look out for. So security architectures, I'll just talk about this because it costs some time. Mhmm. It's one glitch we do have in the, platform at the moment is that, the animations, do not work. But, really, all I want you to think about when we talk about, the security architecture is protecting your data because data is king. And what this animation would have showed is in a traditional application, maybe a fat client application, that client has a lot of access. Because it's got direct connection, a direct path to the database, If that gets compromised, then anyone can then access or someone could put malicious code at the front end or do whatever. And, ultimately, what you want to do is reach the ultimate goal on a thin client, for example, a web solution, a thin client technology, such as Citrix or whatever, and get data away from the client. You can go through a number of different steps to do that such as, implementing a, unit based data server because then all you've got is connection pool credentials through that data server. And from that data server, that's the thing that knows how to get to a database, but it's not actually exposed to the client. You could also think about, an API type architecture where, again, the client doesn't do direct retrieves for the database, but instead goes through API calls. So, again, you're then not exposing database structures. You're just saying, perform this business rule, here's some of the data, here's some of the data. What it looks like behind that is, completely, hidden from the client. But ultimately, just need to think about how do I get that data and access that data layer as far away from the client entry point as possible. Back to you, Michael. So, I mean, we putting a road map in for security is something that's quite tricky to do, because the more we tell people about things, the the the more things can be exposed. So we're not gonna really talk about, you know, we're going to do, you know, this feature, that feature, and the other feature. But it's probably worth just sort of, just letting you know, you know, where we where we concentrate on doing security. Yeah. So, customer feedback is something that we always welcome. Yeah. So, you know, please contact us and talk to us about concerns because that is something that allows us to be able to to understand requirements more thoroughly and make sure that we produce something, that that's good. Yeah. We, you know, we we base, a whole, you know, all of our code and all of our third party packages and and and that kind of stuff is all goes through this, this this scanning tool to to make sure the licenses is correct, the, CRVs are, you know, what CRVs are in there, etcetera etcetera. Yeah? And based on that, we will do triage to discover, you know, which component we should be working on. Yeah. So, you know, in the in the last as we've gone on in the in the recent weeks or re we recent number of patches, you know, we in this patch released, I think, today, you know, we we took out a a number of, plugins to enable old versions of browsers to work because there were security vulnerabilities. You know, we, have updated OpenSSL. We have updated curl. We have updated etcetera, etcetera. And we go through, and making sure we update them. But we go did go through a triage as well. So, you know, we will look at a individual response vulnerability, which should be, reported in that base package to determine whether we're actually anywhere near that code within you know, from within Uniface. Yeah? Because quite often, you know, there there is a a a very large library, but we only use a a relatively small part of it. You know, so, you know, if if it's not vulnerable from within Uniphase and there is something that that is is more pressing, we will obviously go for the more pressing one first and and and go through that triage process. You know, static scans, you know, we every every time we do a build or every time we release a patch, we we go through and we we make sure that we have not introduced any more vulnerabilities into the into the product. You know? There's there's nothing being reported from from this product. Yeah? And every so often, the tool gets updated. We get a whole bunch of new information, and we are continually going through every patch tends to have, you know, small updates, which are which are coming from the the stat static codes code scans. As people as, you know, as time goes on, as these tools get better, we get more information. So the product continually improves, and becomes becomes more robust. And we tend to, you know, we tend to yeah. We run through pen testing. We're due for another pen test sort of now. So that that's something that that we need to we're going to be organizing and it's gonna go through a pen test. You know, this is an interesting one because we can test our environment. However, you know, we can we can go through and harden our environment and make sure that it goes through the the pen test. Yeah. You know, if you if you are exposing applications, yes. I will. Now I would recommend that on your application, it's it's probably worth coming through a similar kind of process, because it's application code as well as the WRD and the Uniphase technology stack. Yeah. And, you know, currency is, you know, cannot be, being on supported versions of databases, supports versions of operating systems, and that kind of stuff. You know, a lot of a lot of security vulnerabilities are are being, addressed as part of that. So these are the things which we will go through, to, be able to determine, you know, what security stuff we're working on first and and and what we're gonna be working on immediately afterwards. Yeah. So but, unfortunately, I I yeah. We we can't go through and and talk about individual things unless they've been released. You know, in the in the last couple of patches, a seed has been released in the assignment file for the encryption. I'd recommend using it. We got a minute and a half left. Well, I was gonna say I mean, I I think we can stay on a few more minutes. I'm gonna just remind everyone about the survey. I'm gonna launch that in just a few seconds. But, feel free to, you know, continue to ask questions even if it's not security related, and we can cover some of those in the next few minutes. So Michael and Jason, if you wanna and and, Jorge, if you wanna take a look at any other questions that have come in and talk about them live if you want to? But I'm gonna go ahead and watch that survey. Any way to get the precompiled code tree? Yeah. By me. Okay. So the pre when you say precompiled code, code tree, you mean the the CMI, I suppose. CMI is a a file in the operating system. It's in JSON format. It's structured about, you know, and and gives you that information. I'm assuming that's what you mean. So Sorry. So I I see one come through from Jean Jean Marc, around being able to store external keys. Yeah. So I I would recommend, you know, either integrating with the key store or in the asylum file, pass scrambled would be the the best ways that I would I would consider. Jason, would you got any other ideas on that? Well, I just say to clarify the potential problem with encryption, that was specifically with regard to passwords because if the passwords are still encrypted and that encryption key gets compromised, then that whole password database is encrypted. So you just need to pick when do I need encryption and when do I need hashing. If it needs to be reversible, then you are going to have to encrypt. If it's just for a verification type practice, then use hashing. When I'm not aware of, something that does code scans at uniphase level. What we are doing is, you know, we we are investing in artificial intelligence and code editing. And, you know, we were expecting for us to be able to sort of give information about, you know, possible problems within code. Yeah. These are these are still early days. It's not long now when we're going to be releasing a a a a coding assistant, a bit like a chat GPD front end. You know, we're we're looking at, sort of authorization to release it and, and username and password handling. But, yeah, that that's pretty much close. And then we're gonna be going on to do much more DevOps side of things. Hopefully, that's that's gonna be able to give us a a greater insight into into, code. I think that's about it, isn't it? Yes. You've handled all the questions. Alright. Excellent. I'm sorry to hear that. Yeah. Well, thank you all for joining us. I think it was a really good session. I like the, the fireside chat, format, which we had Jason. It was great. Well, again, thanks for joining everyone. I I am gonna get the recording sent out to you, I'm hoping, by Friday. And if, if not, it'll be Monday, but I will also be posting on the forum. So go take a look there. Somebody said that I'm muted. Am I muted? No. No. No. We can hear you well. Thanks for bearing with us with our new platform. I actually like it a lot. I think by next time, we'll be a lot more comfortable. But reach out if you have any questions, and, we look forward to seeing you next time. Take care. Thank you very much, everybody. Thanks, everyone. Goodbye. Thank you all. Bye bye.