Modern Strategies and Tools for Securing Internal Applications

The rapidly changing digital landscape requires dynamic and robust security strategies. In this webinar, we delve into cybersecurity strategies and tools necessary to secure your internal web applications (admin control panels, internal dashboards, CRMs, and more). 

This session will equip you with the knowledge to navigate the ever-evolving cybersecurity landscape and develop effective security strategies for your internal web applications. This will involve understanding the vulnerabilities associated with these applications, the potential risks they pose, and the modern tools and strategies that can be implemented for their protection. 

Understanding the unique security challenges of internal web applications

Exploring best practice security strategies and how to adapt them to your unique needs

Reviewing the latest security tools and how to effectively implement them

Learning how to maintain the security of your applications in an evolving cyber threat landscape

This webinar is ideal for IT professionals, managers, and business owners who wish to enhance their understanding of modern cybersecurity methods and tools, and their application to internal web applications. It offers practical advice, real-world examples, and actionable steps to improve your organization’s internal cybersecurity posture. Join us to future-proof your organization against emerging cyber threats and ensure that your internal applications remain secure and robust.

Key topics on Modern Strategies and Tools for Securing Internal Applications

You can use Teleport to enable secure access to internal applications.

Teleport Application access provides end-to-end protection of traffic with encryption and integrates with a lot of existing technologies.

Teleport offers the Community edition (open source), the Team edition (cloud-hosted in Teleport) and the Enterprise edition (cloud or self-hosted options).

Transcript - Modern Strategies and Tools for Securing Internal Applications

: 00:00:04.528 [music] Caesar from Montreal, welcome. I was in Montreal not too long ago. It was absolutely beautiful. [music] 

: 00:00:29.200 Okay. I'm going to pause the music here. And give me just one moment. I'm going to switch my microphones. Okay. Hopefully, you can hear me a little bit better now. Hello and welcome to everyone joining us from around the world. We've got several folks from outside the US, as well as folks here in the US. I'm Travis Swientek. I'm located here in Austin, Texas. So thank you for joining us today. This is going to be what I like to call a lightning webinar. It's a quick 30 minutes. It may not even take us 30 minutes to get through the material that I plan to present today. But what we plan to do at the end is to have plenty of time for questions. So do keep an eye on questions or rather keep your questions at the top of your minds, and here at the end, there will be an opportunity to ask those questions. You can also throw the questions in the Q&A component. I believe if you click the little tabs up there at the top, you should be able to ask a question. And we'll get to those questions here at the end. But let's dive into it and get started. So again, thank you for joining today's webinar. Again, my name is Travis Swientek. My official title here at Teleport is I'm a product marketing manager. Though I'm not your typical marketing professional. Rather, I have a pretty diverse background working in many different highly technical roles from software development to technical account management, primarily in the startup world. So as many of you probably know, in the startup world, you wear a lot of different hats, so I'm exposed to all different kinds of the — or all different areas of the business, rather. But as a former full stack engineer, I experienced a lot of the firsthand challenges that you may be facing or that DevOps teams may be facing that we hope to solve with Teleport. And we're going to talk a little bit about that today. 

: 00:02:23.357 So let me advance the slides here. Today, we're going to cover a few things. Particularly, internal web apps. So the first thing I want to talk about is those pesky internal web apps that you have. Maybe your organization has internal control panels, dashboards, and whatnot. They could pose a potential risk for your business if that information that's within those web applications lands in the wrong hands. So we're going to define what internal web apps are. I'll talk about all the different kinds. We're going to cover a few challenges and problems, and then we're briefly going to cover a few improvements that you probably should consider to improve the security of those applications. And then finally, we'll close out with how Teleport can help you solve those challenges. You joined a Teleport webinar, so I have to talk a little bit about the Teleport product, but hopefully, you learn something along the way. And then at the end, we're going to have plenty of time for questions. So again, throw your questions in the Q&A. We'll get to them at the end. I created a slide also that summarizes all the important parts here that you can easily screenshot at the end. So get your screenshot tool ready at the end. I'll let you know when it's a good opportunity to screenshot the slides because it's a really nice summary of everything along with links and links over to our Slack community and all that good stuff. But if you do miss it, if you do have to run, no big deal. We'll send you an email with a recording to this webinar. You can watch it later. Okay, so let's dive into it. What are internal web apps? In a couple seconds or less. That could take a little bit longer than a couple of seconds. But the first thing we want to talk about is what are the common characteristics of internal web applications. 

: 00:04:07.561 So first off, we have limited access. So typically, internal web applications are only accessible from within an organization's network. There's usually some sort of network access control that prevents someone from accessing these applications from an external public network, right? Typically, you would access these apps via VPN. You'd use a VPN so that you can get into that internal private network, and then from there, you can access the web app. A lot of these web apps are purpose-built, right? A lot of startups, what they'll do is they'll build out something with like a web framework like Django or Laravel or Ruby on Rails to build out some sort of internal control panel that ties back into their main application so they can adjust subscriptions or send invites to potential prospects and things like that. So it's typically a purpose-built or custom-built application — web application, to be specific — that's deployed within a private network. Sometimes these things can have sensitive information, and since these apps contain sensitive information, they should probably have some robust security measures in place, but not always. Sometimes we always just lean back on our limited access, where we have network controls that prevent folks from accessing these internal apps. But there's risk there, right? There's risk in that if someone does breach that internal network, you could potentially access this web application. Complex integration. So there might be integrations between different systems. Maybe you have a CRM that's separate from your actual customer account database and things like that. So that's an area of concern. 

: 00:05:53.010 You might have something that facilitates collaboration. So maybe there is a file share or — I hate to say SharePoint. We might all cringe at the term SharePoint, but something similar to SharePoint where you have this sort of internal intranet that holds a repository of docs for collaboration. You might have a panel that allows you to perform maintenance tasks or maybe even a CI/CD tool like Jenkins or [inaudible]. And that's a good summary of all the different characteristics of internal web apps, but next, let's talk a little bit about examples. So first, as I mentioned, self-hosted systems dashboards. So we see these a lot with customers. Grafana, Kibana, Kubernetes dashboards. Now, don't get me wrong. There are cloud-based versions of these tools that allow easy integration with an identity provider. However, there are certain self-installed or self-hosted versions, the open-source version of these tools that maybe don't have those components. Or maybe you're a startup and you don't necessarily have an item key at the moment, and you're just using basic authentication to access these tools once you've gained access to your internal network. It might be admin control panels, feature flag controllers, deployment tooling, CI/CD Jenkins, those types of tools. CRM tools, HR systems. I think SugarCRM is a real popular alternative to Salesforce that's self-hosted. Now, again, it probably has SAML or OIDC connectors that allow you to connect in from your IDP, but sometimes businesses are just not ready yet. They're not ready to implement a full IDP, and so you're using just basic authentication. Internal knowledge bases is another good one. Wikis, internet portals, I mentioned earlier. And then there might be some inventory management systems, factory automation panels. There's probably a much longer list here, and I could go on and on about different types of internal apps. But yeah, this is probably a good summary of those. 

: 00:07:58.876 Now, let's talk a little bit about the challenges and problems that you're going to run into as you maybe are launching a new business and you're building something from scratch and you need some sort of admin control panel. Here are some things that you should consider. So problems with internal apps. One, they might lack authentication and rely strictly on network access control. I've seen this before in my past. I won't name the company, but we had tools internally that were only accessible once you got on the VPN, and you really didn't even need to log in to the actual tool itself. Of course, you had to authenticate with the VPN, but once you were on the network, you could access the tool. And from there, what's the challenge with that? Well, you really have no auditing or activity reporting on that to see who did what. What happens if someone suspends a customer account? Maybe they did it for a good reason, right, but there's no logging or tracking there. So your support team is going to be wondering, "Well, how did this get suspended? Why is it suspended?" and so on. So authentication is a really important component of building an internal web app, but often we're seeing web apps that lack authentication. For those that do have authentication, generally, what I see is that it's just basic HTTP authentication, the old-school pop-up on your screen. Once you access a web page, it's sort of the in-browser username and password, you type it in, you hit Okay, and then it finally actually loads a page. Generally, those are static credentials that are tied to some sort of web server that's got the basic authentication configured on it. And that's not always a good thing, right, because it's probably a static credential. Also, the technical implementation of that effectively just Base64 encodes the username and password, passes it to the backend, whatever that is, a web server, whatnot, and then from there, it Base64 decodes. 

: 00:10:00.860 And as we probably all know here, Base64 is not an encryption method. It's just an encoding method. And so if you don't have TLS encryption on the network level, anybody can inspect the network traffic there and pull that Base64 encoded string out, and now they have the username and password. So if someone has compromised your network, that could be a challenge. Also, roles. Roles are a big thing. So generally, what we see is just one role, of one admin role, that's configured. There's limited or no permissions. And if someone has a username and password to access this backend tool, they might have the ability to do something potentially destructive, and sometimes — I am guilty of doing this. I was clicking around very quickly and accidentally deleted a customer's email. I was working at a Microsoft Exchange shop, but I accidentally deleted the user account just because I was clicking around too fast. And I shouldn't have had those permissions, right? I should have had a role that prevented me from being able to delete a mailbox, but in that case, I had full admin permissions, which was not a good thing. Some other problems that you'll probably run into is SSO. Generally, setting up SSO internally on an internal app is pretty low priority. I mean, there's a lot of tools out there — Let's Encrypt, Certbot, and things like that — that make it a lot easier to set up SSO for internal apps. But still, what we see is a lot of new apps that are being spun up want to get things to market as quickly as possible, so sometimes we skip SSO, and again, fall back on the fact that, well, maybe we have network isolation here where it's not going to be an issue. But the moment that that private network gets compromised, now you're going to have an issue, right? So you should be proactive here and make sure that you do have SSO on that internal traffic. 

: 00:11:59.476 Another problem or challenge that we've seen over the years is missing critical security updates. So a lot of new startups that go and build internal control panels and web apps and things like that, sometimes they have a very small crew of developers and no [inaudible] at all. I totally get it. Sometimes you just need to spin things up and get to market as quickly as possible and get that revenue coming in before you can actually really go hard on security. And sometimes you miss critical security updates. There might be a vulnerability on the platform that you're using. Maybe the application, maybe you're using Django, for example, and there might be a security vulnerability that doesn't get applied. The server, the database. There's all these different components that you need to keep up to date and perform maintenance on those things. Now, not so sure Teleport will help with those issues, but in a way, it does prevent folks from hitting your application. We'll talk more about that here in a moment. So it's just something to consider. Limited sanitization of inputs is another challenge. So again, as you're sort of an indie developer or maybe a startup shop and you're building out a web app, you might not be thinking too hard about these validations on your inputs. You might have SQL injection or cross-site scripting attacks. Oh, that's a tongue twister. And that's okay, right? It's an internal app, so maybe you don't want to put forth all the effort to go add all these protections to your app. But if someone, again, is in that internal network, they could potentially leverage those as an attack vector. And then lastly, it's zero visibility and activity in audit of actions. So a lot of these control panels that we're seeing being built out there that are being put behind Teleport, they really do lack any sort of activity or audit logging. 

: 00:13:59.660 Again, generally just trying to get something spun up as quickly as possible in audits in activity tracking is pretty back of the mind. It's not something that folks tend to prioritize. So how can we improve internal web app security? I'm going to talk through just a few things that you can do. As I mentioned, this is a Teleport webinar, so I'm going to tell you about Teleport. But first, I want to give you a couple of tools that you can employ yourself. They're pretty basic, but it's worth talking about them. And I want to hear your questions as well. So how can you improve? Here's some potential solutions. One is you can easily implement authentication using an IDP. IDP stands for identity — what does it stand for? Identity platform. Generally, this is something like Active Directory, Okta, Auth0, these big SSO providers that are out there. So if you implement authentication utilizing an IDP, you can enjoy single sign-on, you enjoy mapping of users and roles to your application, and so on. So a couple of pros and cons. I've kind of already mentioned the pros. The cons: you need an IDP, you have to pay. Right? Okta, Active Directory, Keycloak, a lot of these things aren't free or maybe they are open source, but you still need the infrastructure to run those tools. And then your app must be — or rather, it must support SAML or IDC, JWT, or something like that to handle the request coming from your identity platform. Second, you could set up basic HTTP authentication with static credentials. That's good, right? It's a good initial safety precaution. You can require a password to access so that it's not just a VPN that grants access to the tool. It gives you some protection, but as I mentioned, it's easy to intercept the network traffic here if it's not using TLS, SSO encryption. Also, static credentials most likely, unless you have additional plugins set up with the web server that connects to LDAP or — I think FreeIPA is another one that's out there for Linux environments. 

: 00:16:06.414 And then lastly, no real granular control, unless you've got — well, unless you build it, honestly. But depending on your app, if you're using something like Django, Ruby on Rails, you might have some add-ons or plugins that you can enable that might help with this, but generally pretty limited if you're doing basic authentication. Third, it's configuring role-based access controls. So the pros here is that most frameworks have RBAC modules, right, like Django, Laravel, Express. You go search on all their plugin directories, and you'll find some sort of RBAC if it's not already built into the tool. The cons to this is if you're not connected to an IEP, you're going to have a user and role management challenge in that you have to manage all of that inside of the tool separately from maybe your SSO or your IDP for computers or any other systems that you might have connected to an IDP. So the benefit here with configuring RBAC is, yeah, you do have fine-grained access controls, but you really need to connect that to an IDP to enjoy the benefits and not turn into a maintenance nightmare. A couple of other items. Add SSO to encrypt network traffic, we kind of already talked about this one. It limits the man in the middle of [inaudible] if someone does infiltrate your networks. It prevents the credentials from being easily sniffed. The cons to this is it doesn't actually require a domain, but you can get away with doing a self-signed certificate and doing encryption that way. It's a core user experience. But if you want to do it right, it requires a domain. And with that, you're going to have to do some certificate maintenance. Certbot does make it easier to renew certs, but there are some challenges there with the certificate validation, whether you're going to go with the DNS validation or the HTTP validation to prove that you own that domain. So a little bit of advanced setup, but something that is not too difficult to do these days. 

: 00:18:07.205 You can limit network access with VPNs. I'm sure you're all familiar with that, right? Anytime you're accessing these internal tools, if you're on a VPN, that entire end-to-end network connection's encrypted, so that's good. Cons to that is pretty complex infrastructure. And there might be some capacity constraints, especially as your company grows or you have a big swing of everyone moving from an office network to a remote site, and then you have a ton of traffic going through those VPN concentrators. They can be oversaturated pretty quickly, and it's a really core experience for everyone, especially someone who's watching YouTube over the VPN, right? If you don't have your VPN configured correctly and you're routing all traffic over the VPN and someone's Netflixing, you're going to zap up all the traffic and that's not going to be fun. So Teleport Application Access is what we're all here for. I'm going to talk through a couple of features and how Teleport App Access can be used to solve all of those challenges that we just talked about. And here at the bottom, modern internal web application security tooling. That's the best way to describe Teleport App Access. It's modern because it integrates with a lot of existing technologies. It's going to integrate very nicely into your existing stack. There's a lot of flexibility with the tool as well, whether you're doing SAML, OIDC, JWT. If you want to integrate with Okta, Active Directory, we've got connectors for all of that. So here are some benefits of application access, and I'm going to show you — I have a couple of diagrams to share with you on how all of this stuff works, but let's talk through the benefits real quick. One, with Teleport App Access, you will enjoy end-to-end encrypted protection of that traffic. Right? So as traffic traverses from your laptop to the actual web server who's hosting your backend application, it will be end-to-end encrypted and Teleport will ensure that. 

: 00:20:01.044 You can limit network access to authenticated users. So this is very similar to the benefit for VPNs, right? You are limiting all the network access so that only network access coming through Teleport can access. And furthermore, they have to be authenticated. You can utilize SSO, so using an IDP and using our IDP connectors, you can do SAML, OIDC — what was the last one I mentioned? I forgot. SAML, OIDC, and JWT. Those three protocols are supported in Teleport, and yeah, you can set up SSO very easily. You also don't need an IDP. Teleport can act as an IDP. So Teleport does have the capability to maintain users and groups internally and be the IDP for your application. So if you are a startup and you don't necessarily have an IDP just yet, use Teleport. Teleport can be your IDP and can easily give you SSO right out of the box. It's pretty sweet. It's not something we generally market, I believe, because we're not trying to compete with Okta or anything like that. But if you're a startup and you need something quick to spin up, Teleport is there to help you out with that. App access allows you to eliminate a lot of those static credentials or passwords. So the way that Teleport works is if it's connected to an IDP, your IDP acts as sort of the central component for users and groups. And with Teleport, you're eliminating passwords because you're interacting with your IDP. And however you authenticate into that IDP, whether it's with multi-factor authentication or whatnot, once the SSO connections are established to Teleport, all of that is using encryption. It's using certificates to validate to ensure the identity as it traverses across the various systems from Okta to Teleport. And so from there, once your session is generated inside of Teleport, you're not using passwords at all, right? You're using the certificates that Teleport has generated for you. And those certificates will be used to access the infrastructure, including the apps. 

: 00:22:05.309 You can enable phishing-proof MFA. So multi-factor authentication is really important as phishing continues to increase and increase. So with the Application Access, you'll enjoy multi-factor authentication, whether you push it up to the SSO or have Teleport handle that multi-factor. Role-based access controls, we talked a lot about that, and I'll dive a little bit deeper into that in just a moment. I'm going to speed up just a little bit because I'm looking at the time. And I want to show you the charts. But the last thing here is audit and activity monitoring, which is a pretty cool feature of Teleport. So I talked about network security and securing end-to-end. Very similar to a VPN. What Teleport does is here between the public network and the Teleport proxy, we're using TLS, HTTP traffic. So when you're interacting with the Teleport proxy, all of that network traffic is encrypted. It's using the same encryption technology that you use when you're interacting with your bank or with any other highly secure web application. And then from there, once your traffic hits the Teleport proxy, it then communicates with all of your resources. What I have listed here is a control panel, Grafana and Jenkins. I'm only showing you App Access components. And if you look at Teleport's website, you'll see we do far more than just App Access. We do Server Access, Kubernetes Access, and so on. And it utilizes the same technology underneath the hood, which is basically wrapping the network traffic, whether it be HTTP or TCP, over an SSH tunnel. As we all know, SSH is encrypted, uses encryption by default. Therefore, all of the traffic end-to-end here is encrypted, which is great. 

: 00:23:42.749 Here is a diagram where SSO or an IDP is implemented here. So I threw Okta in here, and the flow is like this. You start off at the public network. You authenticate with Okta. There, you might have some sort of multi-factor authentication, whether it's a password, and then an app that you have on your smartphone and whatnot. After you've successfully done that, then SAML OIDC is used to pass the validated identity, which includes users and groups, down into Teleport. Teleport accepts that and extends that information to your web apps. So your web apps there can enjoy the mapping of users to groups. And then lastly, audit logging and activity logging. Teleport does really good at auditing and tracking activity. So as an administrator, if you want to see who's doing what in what applications, you can go to Teleport's audit log and take a look at these session data. We track all of the data around what user accessed what application, IP addresses, and all that good stuff. On the right-hand side, I'm showing you different icons for different tools. So Teleport allows you to use things like Fluentd to push data from our audit events into Splunk, Elastic and Sumo logic. And I believe we also have a couple of other connectors for Logstash, Fluentd, and things like that. Check out our website for more on that. But you can take this data into your SIEM and do more with that data. So that's about it for the webinar today. I want to talk to you a little bit about the packages that we offer with Teleport. So first, we have our community solution, which is completely open source. So if you're a new startup here and you're not ready to dive into a paid engagement with us, check out our open-source solution. You can spin up a Teleport cluster in your own environment. If you don't want to handle deploying a Teleport cluster, our Team solution is perfect for you. Sign up for our Team solution. It's only $15 per user. It's super cheap. Plus, there's a 14-day trial there for you to kick the tires and play around with everything, see the value of the product. 

: 00:25:47.720 If you've got a much larger deployment and you want to talk to us about a really complex integration, give us a ring, hit that Contact Sales button, and we'll be in touch and we'll talk about your advanced use case. So here's a slide that I mentioned before with all of the different things we talked about today. Screenshot this. There's all the benefits of app access. A couple of links that I threw in there. So sign up for our 14-day trial. There's the app access docs. You can download Teleport if you're interested in the open source. If you're interested in contributing to Teleport, check out our GitHub repo. You can see all of the code there to even validate and ensure that we're doing what we're saying we're doing, right? You can see the actual code there. And then lastly, join our Slack community. It's a really vibrant community. There's thousands of people in that Slack channel talking about all different kinds of interesting use cases. If you think you have a use case that we haven't seen yet, I will challenge you, go search in that Slack, and you're going to find someone talking about something. It's really cool to see everyone and how they're using Teleport. So yeah, with that, I'm going to dive into a few questions. If you want to stick around for a few minutes, that's cool. If not, hey, grab the recording, and — all right. So let me pull in these questions here. How does SSO come into play with authn? That's awesome. It's a good question. So hopefully, you grab screenshots. I'm going to go back a couple of slides so that I can talk about that here. So authn is authentication. So SSO and authentication — so actually, let me explain the difference. Authn is authentication. Authz is authorization. So authentication is the act of using a username and password to log in to something. And then authorization, authz, is — do you have the roles and the right to do this? So how does SSO come into play with authn? Well, SSO is the act of single sign-on, right, of using something like Okta and IDP so that Okta is your central point of users and groups and things like that. 

: 00:27:54.350 And Teleport will trust the Okta identity platform, and as you authenticate with Okta, it will pass a payload of information using something like SAML or OIDC over to Teleport. We'll parse that information, pull out the relevant bits, your user and groups, and then map those to users and groups inside of Teleport. We've got a really good doc on our site about that, so check out our documentation. And yeah, there's a lot more there in the docs that explain it in detail. Any other questions? Actually, we're about at the time, so I'm going to cut it there. If you do have any other questions, please throw them in the chat, and I'll shoot you an email after this to answer your question. Again, let me go back to the end here. Grab a screenshot of this if you haven't already. There's a bunch of good information here. But thank you so much for joining us today. Hopefully, that was interesting and helpful as you embark upon building any sort of internal application and want to protect it. Using Teleport is a really great and simple solution for protecting those web apps. Again, you can sign up for Teleport team 14-day trial to test it out, kick the tires. And after that, it's only $15 per user per month. Hope you give us a try. Thanks for joining, and we'll see you next time.

This session will equip you with the knowledge to navigate the ever-evolving cybersecurity landscape and develop effective security strategies for your internal web applications.