 Good morning, everyone. Nothing like Guns N' Roses at 9.45 in the morning. So let's kick this off. Welcome to the jungle. You're at challenge. Build a secure app. So we're going to talk all about the things we can do to build a secure application. We'll make it fun, too. The game originally was supposed to be around the reboot movie, Jumanji. But I was told I couldn't do that. We didn't have permission to do it. So it helped me. I had to go ask ChatGPT for an equivalent, so a coding game that's themed like Jumanji. And this is what it came back with, which was pretty cool. Code Jungle, the secure application quest. Developers must navigate through a treacherous virtual jungle filled with cyber threats, puzzles, and security challenges. And your mission is to write a secure application that can withstand the most cunning of cybersecurity attacks. The fate of the virtual world hangs in the balance. And only by mastering the art of secure coding can they emerge victorious from this adrenaline pumping quest. So I thought that was pretty cool. And it helped me check the box on including AI in my presentation. So all right, a little bit about me. Again, my name is Rob Truesdale. I'm your jungle guide today. I think the Nile was equivalent in the movie. Spent a lot of time in cybersecurity, spanning development work, QA, testing, security engineering. Now I'm in product management at a company called Pangea. You can see some of the skillset that I've worked on in the past. On the personal side, I'm going to pretend outdoor guide. So this was kind of fitting anyhow. And then I'm also learning Snapchat. I had to use Snapchat to make this image. So that's the first time I've ever had to do that. OK, so let's dive in and learn a little bit about the player profile, so yourself. How many in the room just show your hands? Are software engineers that are working on apps for a startup? Raise your hand. OK, awesome. Cool. What about software engineers that are working on enterprise B2B apps? OK, more, yeah. And then software engineers that are working on more consumer-facing apps. OK, great. So now that we haven't understand the players, let's talk a little bit about the instructions. So this is something you can Google around about. Jen Easterly, who's the director of the Cyber Security and Infrastructure Security Agency, along with the FBI, the NSA, and six other countries, have published guidance on how to build more secure applications. The campaign that they're building is trying to influence software builders to take security much more seriously and embed security directly into their application rather than putting security or the obligation of security onto the people deploying the tech or the users using the tech. So you can Google around and look at this paper. I definitely recommend it. They talk about a wide variety of things, spanning from memory-safe programming languages to SBOM analysis and code scanning to deployment tactics all the way to and what's highlighted in the red box, secure software components. That's what this game is going to revolve around today. What are the components that you all can put into your application to help you build a more secure experience for your users and secure your application? Now, some interesting findings throughout this game are the journey of building a secure application. At Pangea, we did some research with a partner group, the Enterprise Security Group, and surveyed thousands of developers about their perspective and relationship and tactics when it comes to security. And what came out of that research was pretty interesting and I don't know if this is something that any of you have thought about or encountered, but the stats are interesting. 76% of apps that these developers were working on interact with personally identifiable information in some way. So that includes things like financial information, health information, social security numbers, really anything that could identify an individual. So that's somewhat alarming, meaning we have to do the right things as application developers to make sure we're handling that the right way. More stats. 80% of developers admit to submitting insecure or non-compliant code due to the pressure to innovate. So we all know the name of the game. It's more features. How do we get more features faster to either satisfy a customer need or deliver a better user experience? And so feature delivery tends to be the number one priority. And this research shows that. Now the challenge that we run into with that are how do we do that while maintaining a high standard of security? There are ways that we can do that. We'll cover that in a few slides. 84% of developers say the security team is a hindrance that they try to avoid, right? So this is the classic tug of war where I think there's some people who have the perspective that security teams could hinder innovation or hinder business. Really, that's a mindset that's changing in the security space where they're becoming more business enablers and they are somebody who slows it down. But developers have this perspective, right? And it's, whether it's true or not, they believe that. So what are the things that can be done to help that? And then lastly, 76% of developers say that their security team views them as a vulnerability, which is a major problem. So we wanna fix that. And this is our guide in how we're going to do it. So a classic jungle map that we'll use to kind of step through how we would build an application that would help relieve some of those stats that we talked about. So it's gonna start with authentication and we move to authorization, secure audit logging, encryption and secrets, management, proper data handling for PII, file storage and sharing, and then lastly, threat intelligence. So we're gonna step through each of these in our maze to escape this jungle. So first, the power pack in secure authentication, what are the capabilities? And we'll hit select on our Nintendo controller to pull that up for anybody who remembers that gaming console. But it starts with authentication. And I think all of you are very aware of that. We're at Octane's Developer Day, so you're familiar with Octa and or Ops Zero. So authentication, a lot of you probably know these capabilities, right? We want web authentication, access to that at least, pass keys, social auth with OIDC and OAuth, magic links, these are all the different things that really we want to make sure are available to us to use within authentication. Passwords are listed last. Of course, if there are passwords, we want complex password enforcement, but I'm even seeing a lot of modern authentication implementations that are disabling passwords by default and almost forcing you to override that if you wanna use them. So these are the things that are just like natively capable that we should be using. Now, how do we score points? How do we score bonus points? Like particularly with that security team, what are the things that we can do as app developers within authentication to make this even better? So to think like a security pro and score those points, doing things like credential breach checks. So when you have a user registration, let's look at that user, let's look at that user account, the email address, the password that they're using, if they're using one, and try to identify if this is an account that's being abused. Doing things like IP reputation check on the origin IP that that user is coming in from. Doing geolocation checks. Doing domain checks on the email that's being registered. So all of these are things that are available to developers via APIs that you can embed within your authentication experience to score those bonus points on the security side. Other things, like so there's a bonus plus plus thinking like legal counsel. Having geo-based user pools to align with things like GDPR, ensuring that privacy policy in terms of service acceptance is included in your auth flow. These are all things that you should be considering when you're thinking through authentication. Now a game hint for developers, don't roll your own authentication. I've talked to a few startups who have gone down that path and it's like why do that? You don't need to. There are so many options out there for authentication, whether it's Auth0 or other vendors or open source. Pangea one as well that you could use. But nevertheless, you don't have to roll your own. It's non-differentiating. Spend your engineering cycles on things that actually deliver value for the application that you're building and focus on integrating an existing auth and solution and add these security features on top. Now authorization, a word on this. The key capabilities that you should have available when you are examining authorization in your app. We have role-based access control, which is something that we're familiar with with most apps. There's also relationship-based access control and attribute-based access control, which are for fine-grained access. And this is a bit of a cheat sheet for you that kind of breaks down the differences between the two if you're new to authorization. So RBAC is on the way right-hand side. That is your classic, more coarse-grained access controls. And some of the problems that lie within RBAC are when you try to get fine-grained access controls, you get this rule explosion problem, which becomes difficult to manage and creates some performance challenges. So the response to that are RE-BAC, relationship-based as well as A-BAC. RE-BAC is really based on a framework called Google's Anzabar authored by Google. And if you've ever shared a file in Google Drive, which I'm pretty sure 100% of us have, that is relationship-based access control. So you have a user, you have a relation, and you have a resource, and then a accept-and-i. So that's really the foundation of what's called RE-BAC, relationship-based. And then A-BAC is really kind of giving you the opportunity of the catch-all in access controls where you can take not only things like ownership or relationship to a file, but also other attributes about that particular user or file, including things like time of day access, a tenure at a company, what organizational group are they in? What are the attributes of the file? What's the originating IP address that you're trying to access a file from? All of these things can be, I should say, taken into consideration when attribute-based access control are in play. So what are the things that we can do to score points? Let's look at, again, the originating IP address, what's its location, what's its reputation score? What type of profile is associated with that IP address? Is it associated with a VPN or a proxy? We can look at those things when we're using something like attribute-based access controls to decide whether we want to permit a particular activity or not. I mentioned time of day access and user profile information already. We want to make sure that we're audit logging any policy updates, and we're going to talk about audit logging next, but these are the things that, again, score points when we're thinking about securing an application or building security inside of an application. Additional hints, and you're going to hear this as a recurring theme, don't roll your own on Z. Don't build your own authorization. I know I've, again, talked to several companies that have built their own apps from the ground up, and everybody who's in that R-back mindset, when they start to look at other, was just say, attributes that they want to start applying permissioning to, they get stuck very quickly, or they used to, and they said, okay, we're going to have to build our own to manage this. There are so many options that are out there that you can take a look at that are commercial, open source, that allow you to integrate an authorization solution via API versus building your own. So the next step in the game, secure audit logging. And this one is probably the most overlooked or the one that will say attracts the least amount of attention from a developer because people think of audit logging, they just think, okay, I'm going to create an event and ship it off somewhere. But there's a lot more that goes into audit logging that developers should be aware of. There are things like tamper proofing. Are we digitally signing our logs? What type of schemas do we have for audit logging? Are we applying encryption? Do we have multi-tenancy support? So these are the key capabilities in that video game power pack we should be thinking about with secure audit logging. Now, how do we score points from a security perspective? Not only is it about logging the right events, but it's also about coordinating with the security team on what events they'd want to see and also what log format would they want to see it in? And can we standardize that across all of our applications? Again, referencing other applications or companies that we've talked to, we find that particularly those that have many apps across a portfolio, they'll build a capability like secure audit log in a very snowflake type way or a unique way for that particular app. And then the next group builds their own audit log, unique for that app. And then the next group builds their own audit log, unique for that app. And all of a sudden you have five or 10 different implementations of the same capability that are all logging things a different way. And there's a lack of uniformity. And not only that, but wasted development time in building that and maintaining it. So, working with the security team to understand what type of schema and what events to log are very important. Also, doing things like redacting PII is important to consider as well where we're storing events about customers or your users. And sometimes there's particular information at an event that you don't wanna be responsible for holding on to. You don't want social security numbers in your audit logs. That becomes a liability for you. So, being able to intercept that data and cleanse it before committing to your audit log is also a great bonus. I mentioned in the last two, and I'll mention again, don't roll your own audit log. You can get these capabilities and integrate via API very easily and save yourself a lot of time and maintenance on building your own. Look for providers that have that. Take it seriously, audit logging, particularly when it comes to ensuring that those audit logs are not tampered with and are secured after you've created the log are very important. The classic move by attackers, which again we probably all know, but attackers are gonna try to cover their tracks. When somebody is manipulating your app or manipulating data or doing something nefarious, the first place they're going to go are the audit trail and try to cover their tracks or augment those audit logs. So, having things like tamper-proofing capability and encryption and digital signatures are very, very important. And it's very easy to get these things now. This is not something you have to build yourself. Okay, next, encryption and secrets. This is our fourth kind of step in navigating this maze. Use a vault that's stating the obvious, but we need to make sure that our secrets and keys are all securely stored and managed the right way. So we need to make sure that we can revoke those secrets. We need to make sure that we have rotation policies and version history. All of these things are important. And if you're rolling your own vault, these are difficult things to do because you're just thinking about how do I generate a key? How do I generate a secret and get going? But there's a lot of things that need to happen after you generate that. Again, back to things like rotation, version history and revoking them. So bonus points. How do we think like a security pro when it comes to these things? We want to make sure that our vault supports things like automated and manual rotation. We wanna make sure that we can support short-lived secrets. Short-lived secrets are great to use, but they're difficult to manage if you don't have the right system in place to manage them and provision and retire them. We wanna make sure that we have secure audit log integration involved with this as well so that when we're making changes to any of these, we're audit logging that activity. We want strong access control policies. So you can see how these start to weave on top of each other. Authorization involved with vault. Secure audit log involved with vault. So all of these are very important to consider when you are thinking about how to manage secrets and keys within your app. And then again, the engineering hint, don't roll your own. Let's find one and use it so that you can spend your time writing apps that are differentiating. Okay, the fifth of these seven challenges, data handling. And I talked about this a little bit on the audit log side and the stats about handling PII inside of your application. It's going to happen. So being able to first identify what that information is is very important and then optionally redact it. And it's, it is an option but we find that most people decide, yes, like we want to redact. So behavioral, it's almost 100% of the time but it's an option. And then there's different variants of redacting. Do you redact on write? Do you redact on read? These are things to take into consideration. But it all starts with let's identify that PII and make sure that we're handling it the right way. So I mentioned already the audit log example. This is a very important one. So when we want to think like a security pro and make sure that we are handling data the right way, let's make sure we're not storing this information in our audit logs. Also, when we are redacting, what type of text do we want to replace that PII with? A lot of times you can just have a general string that just says data redacted or you can have hash based replacement methods and what's nice about that and why security teams like it are, while you can't identify what that information is, you can identify patterns and repeat instances occurring. So this is particularly useful for things like IP addresses. Again, you wouldn't be able to identify the IP address but you could identify that there is something happening over and over and over again from that same source. So hash based replacement methods are great to use. Thinking like legal counsel using location based redaction, so understanding is this an EU based user? If it is, then I have to apply very specific redaction policies against any data that I'm encountering. So again, there are APIs that are out there in services to help you with this and something we need to make sure that we're considering when we're building a secure app. The sixth challenge, file store and file share. Not every application is exchanging files but many apps do. So we need to make sure that we have robust access controls, we have sharing links, make sure that we have highly secure access to those shares. So things like multi-factor auth being enabled, password protection perhaps, having link expiration, access counts. These are all the things when you're exchanging a file, it's much more than just let me throw a file in S3 and give you a link or something like that. We have to take these things into consideration so that our shares aren't being abused for malware distribution. So thinking like a security pro from a developer perspective. Again, audit logging, very important. So all of our file share operations, we wanna make sure we audit log. Doing security checks on these shares. So the incoming IP address who wants to engage in a share, let's run reputation checks on those. The user, let's run user reputation checks or user credential checks on that user and understand if this is coming from an account that's being used for abuse. Let's make sure we have very solid fine-grained access controls on these shares and let's incorporate things like content disarm and reconstruct on the files to really try to prevent or mitigate the risk of people sharing malware through our shares. So other game hints for you. Account sharing for files across users inside of your user pool as well as external users. So you could have, there's a great example that we've talked about inside our company using State Farm, like an insurance agency or any insurance agency for that matter where you have an agent who's an internal employee working on a particular incident and you have external users, the customers of that insurance agency and then you have legal experts inside of the agency. So there's a lot of different stakeholders in a scenario like that that could be sharing the same files. So being able to have the flexibility to have a file share capability in code that can look at your internal employee user pool and how it interacts with shares along with external users is very important and still layering on these security features like access counts, password protection, reputation checks on incoming share requests. All of those things are important to consider when you are looking at exchanging files inside of your app. Okay, so the last one, the last challenge, threat intelligence. So what are the tools that we have or the capabilities inside of the game? We have IP intelligence, we have domain intelligence, file intelligence, scanning, user intelligence, and there's a few others that you can see on the slide. A lot of developers are aware of these tools that are out there but don't necessarily have access to them very easily at least in a way to incorporate inside of their application. When you go to the security side of the house, these are tools that are in their back pocket that they use on an hourly basis. But now what we can do with the right APIs that expose these or start to bring them into the application itself. So ways that you can use this and think like a security pro as you're writing your application are every touch point that you have with a user or with a file or with a domain, you can attach these type of lookups via code and hit an IP reputation lookup or a domain reputation lookup. Again, there are APIs for these that make it really easy. When you have a suspicious result, so if you run an IP reputation check on an incoming IP and you see that it has a malicious score of 100 out of a range of zero to 100, that is incredibly suspicious, right? So we're gonna want to prevent any activity that we can inside of that. We're going to want to make sure that we audit log that and also communicate that to our security team. When you start doing those type of things now, it's making your app not only more secure but it's becoming a great teammate with your counterpart on the security side as well. And it starts to alleviate some of those stats that we talked about before where, excuse me, developers feel like they're seen as a vulnerability to their security team. So we can correct that by using those same tools that they use inside of our app in runtime code. So that's the guide of getting out of that jungle, right? And getting us closer to building more secure applications. You could do a two hour talk on any single one of those topics. This was just meant to kind of show you at a high level the things that are available and out there that you can use in your code. Now, what this really points at, and this is what what Pangea is really focused on are this mindset shift of shifting security left of left. So we've, so most of you have heard of the whole notion of shifting security left, which means instead of or in addition to deploying security in the production level and operation side, how do we move security left into that or further left into that development cycle and start doing things like integration testing, static code analysis, dynamic testing, SBOM analysis, that's all occurring in that integration and testing phase. What we look at are, can we go even further left? And can we start providing components and APIs that developers can use while they're writing and designing their code? So these are capabilities that would go directly in line to the application runtime code. And these are the collection of services that we build and make available to developers. We have secure audit logging, secure object storage, a vault, all the threat intelligence APIs, and I'm not gonna read everything that's on this slide, but the idea are how do we bring all of those capabilities that I just walked through in that kind of maze to escape the jungle, but make them accessible via API to developers. So these are available, you can go up to Pangea.cloud, check them out and start building security directly into your application. So to close, a few things that you can take away and maybe try for yourself or read on your own. The first QR code there is a link to Pangea.cloud and there's a code there, it's Octane 2023. You can get $20 in free credit on the platform and use those APIs. I think it's a $5 freemium credit that you get in addition to that and that replenishes itself over time. So if you use it, you always get restocked and replenished to $5, but if you wanted more than that, if you're starting to really kick the tires with some of these APIs and you want more credits, there's a code that you can use there to redeem more. Our documentation, everything's open, you don't have to sign up to go check out the docs or anything like that. The QR code is there, so everything is, again, API-driven, so the API docs, the SDK docs are all up there. There's a link to our GitHub as well, so lots of sample applications that demonstrate some of the things that we talked about today. And then we have a secure by design education hub, so if you wanted to learn more about these topics, I mentioned that you could do a two-hour talk on every single one of these and I covered it in two minutes, so I didn't really do its justice, but hopefully it gives you an idea and you can go research more on our education hub. But I think for everyone, again, I encourage you to check out the platform, check out the APIs, there's free credits there for you to use. If you have questions, we have a Slack community that you can go to, it's called Pangea Builders. You can Google for that and discover that or go on our website and link to it. And if you have questions, you can reach out to me on Slack, you can reach out to me over email, robitpangea.cloud, and we're here to help. So I think that's it. If you have questions, I'm going to be out in the hallway there and we can talk more about any one of these services or other services that you have in mind and how you could use them. So thanks for your time and we'll talk to you in the hall. Thanks.