Welcome to Cybersecurity Insights, the podcast for the CyberEd.io Learning Community. Our goal is to bring Cybersecurity practitioners the latest and most relevant education and training to upskill and dive deeper into topics that matter in today's modern Cybersecurity world. Good day, everyone. This is Steve King.
I'm the Managing Director at CyberEd and with us on today's podcast is Weldon Dot, who's the Evangelist and the Senior Vice President of Community for Kanji. Kanji is a next-generation device management company that has a solution for Apple device fleets in security and in mobile device management. So welcome, Weldon. I'm anxious to chat with you about the Apple product and what that means to the rest of us that thought we had a very secure product here going in.
Yeah, thank you, Steve. It's great to be with you and your audience here. This is a topic I'm excited to talk about just because I've had almost a 30-year career in and around Apple and managing devices in the enterprise, so looking forward to the discussion today. Great.
So let's just dive in. A lot of people in our audience would say, hey, Apple was supposed to be the secure from the start model. It was one of the key features of benefits to that product. What happened to change that or was that always just a perception or some sort of a marketing ploy?
I'm not sure it was exactly just a marketing ploy, but there definitely was a period probably in the 90s into the 2000s where Apple enjoyed a relatively strong reputation for being secure with the introduction of OS X, Mac OS in the early OTS. We've had at Unix underpinning POSIX permissions, ACLs, all that was built into the model. From the start, there definitely was a good security story there, but as threats have evolved over the last 20-25 years, I think it's time to re-look at that perception and understand that the nature of the kinds of threats that are out in the wild today have changed substantially and that require some new tools and some new thinking to respond to them, I believe. Yeah, sure.
And in somebody like yourself who has taught folks in operating systems around the Mac and around Apple, you would know better than most. Could you explain how the, I know you guys have a product I think called the Country Bridge? How does that, or how do you bridge device management and point and vulnerability that allows you to create the kind of protection that we're talking about? Yeah, I think one of the challenges today is that a lot of the security tools in the past have relied on patching the kernel or getting low-level access to the operating system in order to address some of the concerns.
If we go back far enough, anti-virus was really just about file detection and file hash or a signature-based matching. And the attacks have gotten a lot more sophisticated now with, they're easier to, not easier, they are more capable of mutation and other methods to hide what they're doing than requires a little more intensive inspection of the device to detect those and find them, and that comes at a performance cost and some cost to stability, right, if you're patching into the kernel. So one of the things that's changed pretty substantially in the last five to 10 years is Apple has introduced a number of platform APIs and other tooling in the operating system to make it possible to do the kind of inspection we need, but at a more reasonable level. So, you know, kernel extensions are out.
It's just not reasonable anymore in this day and age to patch the kernel directly. And so Apple has done a couple things. They've provided a new mechanism for system extensions that allow, you know, these low-level tools to work in a safe way. And also the endpoint security framework, which allows access to file system events, again, in a way that's a lot more manageable, it's more performant, and it allows us to achieve the goals that we have with our EDR product.
So there's a blend there, a bridge, like you said, between device management and endpoint security that we think we're in a unique position to enable. One of the qualities, one of the unique attributes of the Apple platform is that mobile device management, the protocol that Apple has implemented in their platforms. That is the mechanism for organizations to give security applications or security tools the entitlements that they need to access things, like full disk access, to be enabled as one of these system extensions. They require an entitlement to get access to the endpoint security framework.
And device management tools is the mechanism that Apple has provided to enable that access. And so if you're going to deploy any kind of security tooling, you need an MDM product. What we've done is we've built that EDR tooling directly into the device management platform itself. So it makes deployment really simple.
It makes enabling those entitlements frictionless for the end user, for the admin who's using those tools. And we think it provides some interesting value in allowing our customers to see device management attributes, all the details about the device, alongside details about the threats that we might be detecting on those devices. Yeah, well, it would seem to some dumb outsider like myself that with the size of the library or store, the Apple store, I guess, is the way you would allude to that. That EDR is kind of the point of ultimate vulnerability, right?
That would be the place that Apple or someone like yourself, the country would focus on as being the primary entry point, I suppose. Is that a fair thing to say? Yeah, definitely third-party applications and software like that is one concern. You know, Apple does have a number of protections in place.
They do scan the binaries that get uploaded to the App Store for known malware or known issues. There's some protections on the endpoint itself. There's a tool called Gatekeeper that quarantines files that are downloaded from the Internet. There's some tooling called XProtect, malware removal tool that are built into the operating system.
But again, these attacks are getting more sophisticated and the ability of malicious software to try to hide itself in new ways and mutate in different ways to hide from those platform tools still, I think, requires some additional EDR tooling on top of what Apple provides to make sure that you're really protecting the organization. One of the biggest threats, I think, is just end-users downloading software from the Internet that may be hiding something malicious. There's some tools I think this will be familiar to anyone, you know, if they use Apple or some other platform. You know, there's software out there that proposes to do good things for the user in terms of scanning or finding issues but actually hides adware and installing those kinds of tools on corporate systems is a loss in productivity and it may, you know, hide something else that's even worse.
Yeah, certainly. And then the bad guys are, you know, happy to work around the native, you know, EDR kind of protections that Apple provides. So I can see why, you know, why the market exists for you guys. I think you've defined some principles that you claim achieve a balance between user privacy and corporate control.
You talk about being transparent and that engenders trust. You talk about embedding compliance early in the process and then you talk about respecting the difference. That all sounds, you know, great. But how does each one of those principles actually map to accomplishing the goal of creating a balance between privacy and corporate control, as you say?
Yeah. I mean, it's a difficult topic for, you know, our age, particularly when so many people are working from home or working hybrid where they're back and forth. You know, it's not enough to just protect the organization at the network perimeter. You can't define that boundary as, you know, when you're in the office, you're protected, but when you're out of the office, we're not.
That boundary, that frontier is really moved to the endpoint. And it's super important for all organizations to look at their exposure at the endpoint that could be in a completely untrusted environment, you know, a hotel lobby and airport lounge coffee shop around the corner or in someone's bedroom. And what we're trying to achieve here is to allow organizations to have the visibility that they need, you know, collect the intelligence that they need, the telemetry they need from the device to manage their environment and to protect themselves against threats. But also respect the user's privacy.
Knowing where someone, you know, just bear with me for a moment, but like location is a really sensitive piece of information. Now, knowing where your employee lives is maybe, you know, less sensitive because if they're employed by you, you probably know where they are anyways and where to send their paychecks and help benefits and all those other things. But if you're tracking the location of that device all the time, and it goes with them, you know, to and from work, you can imagine a scenario where, you know, they may be stopping at their doctor's office at an appointment after work. And you can see if you could see that location all the time.
And notice that they're visiting this location of a, let's say oncologist, that might reveal some information about the employee's health that they didn't intend to share with their employer. And so this kind of always on tracking is something that Apple has taken a really strong stance about that. You know, yes, the device belongs to the organization. It is possible to get the location of the device when needed, but the idea of always on tracking kind of crosses that boundary where it might be invasive into the employee's privacy.
And so the way that it's enabled in kanji is that if a device really is lost, you can request the location. The employee, if they next time they open and unlock their device, they'll see a notification that the location was requested so that it is transparent to that user. They know what it is doing that they've asked for the location, but it does set that boundary that it's not, it's not always tracking location and it's not accumulating a history of all the places that you've ever been with, let's say your corporate phone. Yeah, we can talk about that for a long time.
You know, the you can't have it both ways, you know, and that's that's the reality and the other reality is that we don't seem to care. Right. I mean, we give it up. We give it up happily to a ton of merchants through our connections with folks like Google or whomever we use and and to the merchants directly themselves or to the community platforms that would members of without any consideration around privacy.
And in fact, I would think I'm pretty sure that if you hold the average user, you know, 99% of them would say, no, I don't want to know. Right. I don't care. You don't tell me now.
And I don't worry about it. And so I don't want to know in the future either. Yeah, it's definitely possible. I think our stance is that we would like for, you know, everyone to be informed about what's happening and to be a little more transparent in that process.
We think we think ultimately that helps employers as well, our customers who are using these tools that they can have a very direct and open conversation with their employees about what these tools do what Kanji is doing so they understand some of the limits. No, I understand. Of course, you need to do that. And, you know, that of course, that makes sense.
But in the down here in the real world, you know, folks do what they do and it's very different. You know, than what you're what you're kind of defending there in terms of corporate policy, you know, you know, that that goes back in my mind to the, you know, and the transparency and engender trust questions because if you probe too hard at what you just said. Yeah, I'm going to, I'm going to uncover areas and, you know, obviously, and it isn't just me, but I mean, anybody would say, Hey, you know, that's great. You tell me this, but then you're also doing that and that you didn't tell me about.
So what's up, you know, in any event. The when you talk to customers who are Apple users, what they aren't their customers who say, Hey, you know, the iPhone is secure, you know, compared to other smartphone operating systems. We don't need we don't need any further protection is there. How much, you know, it's a big part of your, your selling motion educational in nature.
Yeah, it can be. You know, it's definitely true that on the iPhone itself and iPad, I put in the same camp that the attack surface on those platforms is much, much smaller, you know, because of the controls that are enabled and some of the, you know, the way that Apple's designed those operating systems, it's a little bit more open, quite a bit more open, I guess, would be fair on the Mac OS side. So companies that are using laptops, you know, it's possible to download and run software from just about any source. If the user is an admin on their device, you know, they're able to override some of the protections that are available.
And, you know, that's an area where we can provide more. But generally, there is this thought that, okay, our risk is managed that our exposure is limited here. And that's where we can get into those education discussions and show that, Hey, there are some places here. We're having trust in the built-in protections is great, right?
We're glad that Apple has done those things on the device, but there isn't a component to report back to the corporate office or the corporate IT about what the current stance is or what security controls are applied. And so that's where tooling like our device management platform and our EDR tool can help an organization view that current stance, the current state of all those devices, so they can report across the organization, what's happening, where the risk is, and what they're doing to manage it. Once you get into an environment where you need to achieve regulatory compliance and provide some proof to an auditor that you're managing the security stance on your devices, then a tool like kanji is really useful because you can show that here's what's happening on each individual device, collect that information centrally so that you can provide the reporting and accountability that's required to pass an audit or to achieve compliance that may be required for your business or maybe just an internal goal that you would like to be compliant in order to show that you're doing your due diligence to protect the organization. And that's where tooling can come in like kanji where, yes, there is built-in protections, but getting reporting, getting visibility on what the controls, which controls are applied, and maybe which controls are not being applied.
You can get that visibility by using something like kanji. Is there a specific compliance legislation that drives business for you and I asked that because I haven't paid much attention to the mobile device management space in the last couple of years, I think, and I'm not familiar with what GDPR has to say about that at the moment. Yeah, I think we're in an interesting moment where more and more companies are finding that they need to comply with some framework in order to do business. And so here in the United States, you know, SOC 2 is becoming much more prevalent as a requirement to do business.
People are expecting their vendors, particularly software vendors, you know, to be compliant with SOC 2. So if you're in the process of building software on the internet or that runs on advice, you know, just showing that your company is compliant with SOC 2 is really important. Around the world, we see, you know, cybersecurity essentials in Europe, in the UK, in Australia, essential 8 is really prevalent. And so companies, I think, more and more are finding that they need to demonstrate, you know, what they're doing, how they're achieving compliance with your frameworks just to do business and to demonstrate to both their partners and their customers that they're doing the right things.
I suspect this is a trend that's only going to continue. Even if you don't have contracts in place today, for example, like if you're a government contractor and you're doing work for the Department of Defense, there's a whole list of regulations that you need to comply with and assert to that you attest that you're able to achieve. A lot of companies aren't in that boat. They're not doing business with the Department of Defense.
But there are still good practices available from those frameworks, like CIS, Level 1, Level 2, NIST, et cetera, ISO 27001, that are useful for companies to employ, right? It's much better to apply these controls to your company early in the process and hold yourself accountable in your own internal testing than discover that you've not taken steps to implement some security controls when you're actually breached. It's much better to find out in a dress rehearsal that you might have something to look at than it is in a life on stage, if you will. Yeah, of course, and that makes a complete sense.
In the Apple world and just for folks who may not know much about that, you've got this category of apps that I think you call on listed apps and I guess I'm curious about how they go through a different app review process, do they not? And somehow they still get that categorization, then yet they end up on the Apple store shelves. How do they get their own compliance from a security point of view? Yeah, there's items that are available in the public app store that if anybody opens up app store on their device, they see what's listed there.
There are custom business apps that are not listed for the public but are available to be distributed through the app store. So a lot of companies that maybe include the app as part of a service or maybe it's for internal use only, they would still leverage the app store infrastructure as a way to distribute their application, but it's not listed for sale in the way that we would think of consumer apps. Those apps still go through Apple's automated scanning for malware, but they don't receive the same level of testing and usability testing and things like that from Apple because they're not available for the public. So that could be an opportunity.
Another issue is just things that are distributed for macOS outside of the app store. And while iPhone, iPad, the only way to install software is through the app store on macOS, you can download just an installer package from the internet and run it and completely outside of what's been done in the app store. So those are some things to consider that difference between what's on iPhone, iPad and what's on the Mac. There's nothing that category doesn't get treated any differently other than what you've described, right, than normal apps, correct?
Yeah, if you're using the app store to distribute your application, it's still going to get scanned by Apple to make sure that there's no known malware embedded inside of that. You've got another category that you call private or internal. What is the differences between those two categories? Yeah, this is something that's changing.
And I think Apple is trying to discourage the use of an enterprise signing certificate to build an application and then distribute it outside of the app store. There were some issues a couple years ago in the news where some well-known companies were using that mechanism where they could sign an app for distribution. And it was meant for internal use. So if you're building an application that would be of use to an internal team, there was this enterprise signing cert that was available.
Some companies were using that to sign the applications and then distribute them to end users or to their customers. And that wasn't really what Apple intended. And it's still signed, right, so it runs on the device without a lot of friction for the end user. But it wasn't going through any of that testing or automated scanning that Apple provided for apps that were distributed through the app store.
So that mechanism they're trying to shut down, they don't want that to be used for applications that go out to consumers or out to the public. But that's something that you can control with device management. The MDM protocol allows you to prevent your corporate devices from running an application like that. You can only accept things that are deployed by the company or you could trust applications from the app store and restrict the ability to run applications that are distributed outside the app store entirely.
But as an individual end user and I have an Apple machine now and I'm working for XYZ company, how do I know that? Do I call Wellgen and say, hey, help me understand here? What is repackaged for distribution and what isn't? And how do I shut these things down or have access to them?
How does somebody learn that? Well, that's good. I think that's part of what we're trying to do with our customers, the admins that use our tools to manage those options. I think one trend in the industry is to provide people with a self-service catalog of applications that they can use for corporate devices so that you can anticipate the needs and not leave the user stranded to figure out on their own how to get the software that they want.
So that's a real popular option, I think, is to provide that own your own internal catalog of software. Now, on a device that's your personal device or BYOD, I think we get into a different kind of discussion around how much control should your employer have over your personal device. But in the case of corporate own devices, I think it's really clear that the organization should be careful about what software gets installed on there. They should allow some freedom for the user to pick tools that help them to be productive, but going through some kind of vetting process and making those available in an internal app catalog is a good compromise, I believe.
Yeah, but you're right, the BYOD issue is a big problem. From my point of view, in terms of, say, a problem, big security challenge, and especially given the expectation of control and privacy with your own device as you're working, you know, very common now that folks are working from home the majority of the week, you know, that's a dangerous dance that seems to me between the admin and the end user on who gets to decide what apps I can bring to my phone, even though I have insisted upon a BYOD policy that accommodates my personal device. So I don't know how you manage to do that. It seems like it would be a real vulnerability.
It can be. I think there's a few mechanisms that companies should look at. If you're using a modern identity provider solution, an IDP, you know, like Okta or Azure AD or something like that, you can leverage their compliance tools, conditional access, access, Okta flows and authorization flows so that you can evaluate, you know, where is the request coming from? Is the request to access this data or use this application coming from a device that's managed by the organization or is it coming from a device that's not managed by the organization?
And that might be one level of decision making where you say, Hey, look, this information, you know, let's say our finance systems or payroll or something like that, those are sensitive enough that we're going to restrict access to those applications to devices that are fully managed by our organization. We're not going to allow you to use your home computer or your personal phone to access payroll information for the company. Something else like email, you might say, look, you know, sure, there's a risk of data exfiltration from email attachments and things like that. But the usability of being able to access email on your personal phone is a benefit to the company, and so we're going to allow that.
And so access to this application is available through a personal device, and we're not going to check to make sure that it's fully managed. And then, you know, I already used a sort of the hypersensitive example of payroll systems, but you could imagine something in between, you know, access to our ERP or CRM needs to come from a managed device. And now we're looking at payroll, we want to actually add additional checks to that. So not only does it need to be coming from a device that's managed by our organization, but it also needs to be in a state that is in compliance with our security policies.
Device encryption needs to be enabled, there needs to be a passcode on it. Some of those basic protections need to be in place before you can access a really sensitive system like that. So there's a degree there that I think companies need to add more sophistication to their setup to be able to say, you know, this class of applications can be accessed from a personal device, this class of application can only be managed by corporate devices, and this other class of even more sensitive applications, not only does it need to be managed, but it's current state, you need to be able to attest to the fact that it's encrypted, has passcode, has these other security controls in place. And you think somehow that companies will be able to sell that to their employees?
I think so. Like in our own situation, like I can access email from my personal phone. And that's definitely a convenience for me, and it allows me to be responsive to my coworkers, even when I'm traveling or on the road. But then there's other pieces, right, access to certain files or repositories, whatever, that I need to get on my corporate laptop in order to do.
So I find that it works for me in my own personal life, but I suppose other people might have a different experience and tuning those policies and getting the right balance is going to be something that each organization will have to look at. Yeah, and they are certainly today too. So the next time we get together here, well, then we should spend a half an hour on that topic because it's important. And nobody has solved that yet.
And the more we acquiesce to the demands quote unquote of the employee population with regard to BYOD and policy, the less we'll be able to make the kind of policy that you just described as not giving you a headache and being able to have that be satisfactory from an employee point of view. I think. And so in any event, it's a highly relevant topic that I think will cause us lots of challenges here in the next year or two. So just finally, again, I'm conscious of the time, what is telling me about the future for Kanji and then I'm curious as to what your view is about why Apple has not tried to dominate the business phone market at any point in time.
They've never ever acted like somebody that wanted to take a serious market position in that space. Yeah, I think one possible explanation for that is a lot of Apple's success over the last 10, it's been what 15, 16 years since the introduction of iPhone. A lot of their success I think can be attributed to their intense focus on their customer. And this is me talking, right?
This is not necessarily Apple's official stance, but I think that Apple has been really successful because of that intense focus on the user of the device. The person who's holding the device is their customer and they've tried to do everything they can to create just an amazing experience. I think that explains their success in the smartphone market that people like using an iPhone. And what's happened is, you know, there's been that sort of groundswell or bottom up desire to say, Hey, I really love this device.
I would like to use it for work as well. But to Apple's credit, right? They've kept their focus on the end user, the person holding the device, and they're not confused about who their customer is. Now, Apple is a big company.
And so Apple is more than just one thing. And I think over the last 10 years, maybe more, right? We've seen a growing number of people within Apple that understand the value that this has to the business customer. And how IT teams need some tools, they need some capabilities to manage these devices in a corporate environment.
So we saw the introduction of MDM in 2010 and it's grown over time to include more and more capabilities. And Apple's done, I think, a very good job of trying to balance the ability of allowing IT organizations to manage these devices in corporate environments. Whilst while not interfering with the end user experience, like MDM can be, or rather what I want to say is, you could imagine a world in which MDM is very invasive and kind of overrides a lot of the experience that the end user has. And I'll admit, sometimes as IT professionals, we want that level of control.
But to Apple's credit, I think they've struck a good balance of still maintaining a great experience for the end user while giving IT teams some more control. We are the beneficiaries of that. You know, the expanded capabilities of being able to manage these devices through the device management protocol that Apple has built, and the new changes that are coming with declarative device management really allow us to do interesting things for our customers. But still, there's that need to maintain the great end user experience.
That's why people want these devices in the first place. Now, that's something that I take very seriously here at Kanji and trying to build our tools and our products, because what we're seeing out in the marketplace is a lot of companies are adopting an employee choice program, where they're allowing their employees to choose the platform that they think they're going to be most productive on. They could choose Windows, they could choose Apple, they could choose Android, they could choose iOS. And the idea is that's going to enable productivity.
It's going to allow those users, the employees to be productive. We want to build tools that deliver the experience that the end user was looking for when they chose an Apple platform as their choice for their productivity platform. We don't want to wash out or erase the differences between platforms. We want to create tools that complement what Apple's doing that empower the user to get the experience that they wanted in the first place.
So that's something that we've chosen as an org. We are not a cross-platform solution. We are an Apple-focused solution because we think there's something important about complementing the native platform capabilities and working in a way that complements the experience that Apple has already created for the end user. Now we just need to do that for the admin as well.
And to give them the control and the tools that they need, we're still delivering that great experience for the end user. Yeah, well said. So I think that gives us lots to talk about next time well then. And I look forward to it.
Thank you for taking the time today. We're a little bit over. And I wanted to remind our folks that I've been speaking with Weldon Dodd this morning. He's the evangelist and senior vice president of the community for Kanji, the Apple-specific device management solution for mobile device fleets.
And I thank you, Weldon, for taking the time today. And it was great talking with you and hopefully we can do it again soon. Thank you so much, Steve. It was great talking to you today.
Great. Thank you. And thanks to our audience. I hope you enjoyed the time we spent together.
And until next time, it's Steve King, your host, signing on. Thank you for joining us for another episode of Cybersecurity Insights. You can connect with us on LinkedIn or Facebook or send us an email at social at cybered.io. For more information about the podcast, visit cybered.io or with slash podcast.
Until next week, stay safe and secure, and we'll see you on the next episode of Cybersecurity Insights. Thanks for joining us.