Episode 303: Application Vulnerability Testing

---

This week’s transcription is brought to you by Alectrona

James Smith:
This week’s episode of the Mac Admins Podcast is brought to you by Kandji. Kandji’s latest release, Bookmarks, lets you give your users, links to the resources they need at work via the Kandji self-service app. You can put in links to websites, repos, files, or other materials, anything that they need. When you deploy Bookmarks along with apps and scripts and self-service, your users can easily install approved apps, run scripts, and find the resources they need for work. It’s all in one app.
To learn more, head on over to kandji.io, that’s K-A-N-D-J-I.I-O, or join the Kandji channel on the Mac Admin Slack to say, “Hi,” and see what they’re up to. Thanks to Kandji for sponsoring this episode of the Mac Admins Podcast.

Tom Bridge:
Hello and welcome to the Mac Admins Podcast. I’m your host, Tom Bridge. And Charles, are you out of winter yet, or is it winter, still?

Charles Edge:
Oh, it is very much winter, still. Every night it freezes over, every day the snow melts. So, the snow pack is reducing, but it makes for even more treacherous driving conditions because sometimes you just slide a little bit.

Tom Bridge:
Doing the electric slide is fun, but not while you’re driving, exactly.

Charles Edge:
Right, yeah, yeah. But it’s beautiful out. It’s super sunny. People are walking around the lake in front of the window that I’m looking out right now, so if you hear my dog bark… He doesn’t mind people walking around the lake, but he’s a Border Collie and part of his breed is to get angry if the people have dogs who look like wolves somewhat, so those Malamute type breeds. He doesn’t get angry, angry, but when he’s inside, he’s like, “Oh, I must protect the sheep from those dastardly…” Anyways.

Tom Bridge:
And Marcus, how are you?

Marcus Ransom:
I’m doing all right. I’m doing all right. I think Alfie must be part Border Collie then, because for a cat, he seems to be upset at anything wolf-like that goes past the house.

Charles Edge:
My cats like to chase my dog’s tail. He doesn’t mind it unless there’s food on the floor, and then he’s like, “You guys have got to go.” He’s submissive to the cats unless there’s food. And then he’s like, “Sorry, guys,” when it matters.

Tom Bridge:
When it matters, I’m still the top of the food chain.

Charles Edge:
Yeah.

Marcus Ransom:
Makes sense.

Charles Edge:
We have a great guest today, and just a little background on that, we have these computers and they, I think at this point, have become truly bastion hosts. Nothing comes in and only that which we want, goes out. They’re perfect when we finish setting them up, then people make changes, put apps on there. The changes we can mitigate. The apps require a little more analysis, especially these days with all the things that can go inside apps. And a common strategy to manage that risk is to employ a reputation-based access model such, as dictated by, for example, Zero Trust.
Another is to test those apps for vulnerabilities, which in a way feeds back into the Zero Trust decision mechanism in the end. But what kind of tests can be effective, especially since those compiled run times don’t exactly tell us a lot what’s going on? There are strings and there are symbols.
But we’ll chat about this paradigm with today’s guest, Niels Hofmans, and look for ways to fill up that task list for 2023. Before we get started, do you mind taking us through what you do and how you got into that?

Niels Hofmans:
Yeah, sure. Thanks, Charles. First of all, my role is Head of Security at Intigriti. And Intigriti is Europe’s largest bug bounty platform… Sorry, the marketing speak. But basically, means that we connect around 50,000 security researchers and let them test for security bugs’ affordabilities on the assets of our customers. And then, basically, those researchers then get rewarded according to the impact that they cost on our customers’ systems.
That makes it quite an interesting setup that we have and leads to very, and I say very, creative ways in how vulnerabilities are found sometimes.
So, I’m head of security. It basically means that I’m responsible for securing our customer’s data, securing the infrastructure of the bug bounty platform itself, the SaaS application, and the brand of the company as a whole.
When we talk about my responsibilities, I can go pretty far, from helping the infrastructure guys secure our cloud architecture, could be about building up detection engineering, could be leading a couple of compliance programs like we recently did SOC 2, ISO27001.

Charles Edge:
Oh, that’s fun.

Niels Hofmans:
All those bits.

Marcus Ransom:
Oh, yeah.

Niels Hofmans:
But yeah, I see everyone nodding in agreement.

Tom Bridge:
I was going to say fun isn’t the right word necessarily. That’s type two fun, that’s not normal fun.

Charles Edge:
I would like to point out that fun starts with, if looked at as an acronym, two words that begin with F and U. Nevermind.

Niels Hofmans:
Cannot confirm nor deny.

Marcus Ransom:
Which rhymes with SOC 2.

Charles Edge:
How did you get into doing that stuff?

Niels Hofmans:
It all began, I have a thing that I always tried to use with my friends it is, when animals could still talk. I was a young guy, very Linux-y. I had a little Manjaro laptop that I took to work. But yeah, then came the realization that actually none of the enterprise applications worked on my Linux machine. I was using Thunderbird, et cetera. Idealistic at first, but, everyone’s nodding in agreement, you’re going to run into issues eventually, so I, basically, had two options. Either I switch to Windows Endpoints, or, “Hey, there’s a cool Mac thing. It’s still a POSIX system, so I still have a shell, at least.” WSO wasn’t a thing back then. Perhaps I should pick that one.
I was a very anti-Apple guy myself in my younger years. And then in the end, I bit a poison and I’m quite the revert now, currently. And that’s basically how it started itself, started digging into the Mac system itself. How does it work? How does it compare to, for example, Linux Kernel? “Hey, Darbin, what is it exactly?” Hey, we’re currently using and suddenly the same Kernel on all different kinds of devices, regardless of hardware, all those things. And that always got me deeper and deeper into the ecosystem itself. And I guess that’s how we ended up here, in the end.

Charles Edge:
That makes sense. And a lot of people in InfoSec have a pretty wide set of responsibilities. And you mentioned the things that you’re tasked with, but what kind of security projects have you worked on in the past?

Niels Hofmans:
It could be about ranging because a lot of my friends will describe me as such, is that I have a pretty wide range of interests, and that, of course, translates into the project that I do.
So I’ve done, for example, development work, for example, writing certain security tooling in Go for customers, could be penetration testing, web applications, mobile applications that client applications, Java, God forbids, or things like that. Could be secure architecture assessments, could be talking about DevSecOps doing certain migrations, et cetera. It goes pretty wide. And then what makes it interesting, I guess. And yeah, it’s going to be the reason why most folk go into security. Just basically, how everything changes from day to day and not a single day or week will be the same. And it makes it fun, in my opinion. Some might call it depressing, I call it fun.

Charles Edge:
You definitely learn a lot when things are moving that quickly. I do think for this episode we’re specifically interested in delving into app-based security, and it does feel like they’re two general buckets that I like to think of, when it comes to vulnerability scanning for apps. One is compiled and the other is post-compiled.
So let’s say I’ve written the sweet, sweet Tic-Tac-Toe game or Dungeon Dweller game in Swift, but I really want to make sure it’s secure before I compile it. So what guidance would you give in that pre-compiled state? And I guess, how would you communicate what you did to anyone who might be looking to consume that app?

Niels Hofmans:
Yeah, sure. I think the most important part of it will be the mindset itself. So try to upfront communicate with, for example, let’s call it the business owner, Mr. Tic-Tac-Toe, and see, Okay, where is our expectation here? Where is potential, the risk profile of the application? What can it do or will it do? And then on the other hand, where is the risk appetite of our company? What are we willing to do? And it could be internally or externally, for example, paying an external party to do an assessment as an example.
So, that would be, my first phase, is setting the baseline of A, these are our expectations, and that can also be translated in, for example, okay, this is going to be the ETA. You can’t be expecting us, for example, to push out an application the next day, since we don’t even have time to look at things.
But let’s be honest and see, “Okay, we’re going to take one week and we’re going to come back to your answers.” And one of the key things is going to be never say no. Something I try to use. Always try to think along with the person that you’re talking to, and try to walk a couple of miles in their shoes and see what are they’re trying to get, what are they trying reach and how can I help instead of always being the block grid itself. So that’s a lot of guru talk, but in general, it’s basically the mindset itself. Then trying to follow a certain kind of framework that could be, for example, OOS has a lot of grids resources about it. For example, the mobile security verification standard, which literally tells you, “Hey, these are the things that you should look for in the mobile application itself.”
More in general, one thing that we could do as well would be trap modeling. So that we’d be looking at, “Hey, these are the potential protectors, these are all the assets that are in my application that could be interesting.” Could be, for example, your email address when trying to store your Tic-Tac-Toe score, for example, could be uploading it to a backend server. What do we know about the backend server itself? Who’s hosting it, batching it, whatever. And then potentially also looking at, “Hey, now what can every actor use as an attack against it to retrieve that asset itself?” And then in that case, you’re going to put those mitigations next to it, and then you’re trying to frame those in some kind of standard. Could be a word argument, could be an XML, God forbids, JSON, whatever.
So basically, to get things rolling, how much you have rolling is not as important as having things rolling and having things fluent because that will accelerate the process. It will also very much heighten the buy-in for future applications and also that other people will come to you and it is far more important than, for example, getting that one finding that isn’t being blocked up in this assessment about a low severity finding that leads us to blocking an upper lease, and then sets a lot of bad temper in the company, let’s say.
So those are a couple of things that we can do. I can keep talking if you want. But there were also lots of open source tunings that we could use to potentially look at the source code itself. Open source, we know that CodeQL from GitHub is there. There’s a couple of open source signature-sets that we can use. We have SimCap, which is I believe, fully open source, which could also run on the source code itself. We have commercial solutions, and then potentially we also have other tips and tricks that we could do, for example, running it on a local Jailbroken device to do security testing on, et cetera. But I think you get the gist, it’s mainly about starting somewhere and then iteratively building upon that process to see where we’re going to end up.

Marcus Ransom:
So if someone was looking to use one of these vulnerabilities scanners, what sort of process would they go through evaluating them, because I’m guessing they’re not all created equal? So, what process would you suggest to decide which avenue to go?

Niels Hofmans:
Not an easy one, for sure, because comparing vulnerability scanners can be very misleading and has led to multiple political wars on the internet. No, but seriously, mainly, I would not delve deeply, technically, into trying to compare multiple vulnerability scanners, unless of course you have the time and for example, they’re open source or you want to go to a lengthy procurement process for commercial vendors.
But more in general, “Hey, what is the profile of the vulnerability scanner?” So for example, is it a super popular one? Is it a niche one? Which one under Stars and GitHub or Bitbucket or whatever. And between the popular ones, which one is most natively supporting the programming language that I’m using? For example, CodeQL is a very popular one on GitHub, but it doesn’t support Swift. So that will not be a good solution. And we’re not going to try to ride all our own signature sets in a custom way to do our scanning on Swift itself.
So that could be a matter… Another matter would be, “Hey, what are the signature sets that are currently supported?” For example, how does the [inaudible 00:14:09] translate into signature set or the mobile security testing guide? Does it include all the specific tactics and techniques described there in attacks in the signature sets themselves, or I know that a lot of, if we’re looking at the commercial site, a lot of vendors actively support the practice of, for example, taking a portion of an application that you have internally, and then just doing approval of concept on that one and then try to compare all the different vendors next to each other.
But just keep in mind, it highly depends on the programming language that you use, the maturity of the vendor for the specific programing language, and of course, on your specific snippet of source code that you’re providing. Could be that, yeah, per accident, that piece of codes, yeah, resulted in a lot more findings for that specific vendor while on a whole set across all your company estate, it might be the reverse for another vendor. So it’s mix and matching, it’s a difficult process.

Charles Edge:
So what you’re saying is to use all of them is the best approach?

Niels Hofmans:
Depending on the size of security team, it could be. No, it depends. Context. It’s going to be the answer for every question you ask. Context is important.

Tom Bridge:
Yeah. But context matters.

James Smith:

Our sponsor, Kolide, has some big news. If you’re an Okta user, they can get your entire fleet to 100% compliance.

How?

If a device isn’t compliant, the user can’t log in to your cloud apps until they’ve fixed the problem. It’s that simple.

Kolide patches one of the major holes in Zero Trust architecture: device compliance.

Without Kolide, IT struggles to solve basic problems like keeping everyone’s OS and browser up-to-date.

Unsecure devices are logging into your company’s apps, because there’s nothing there to stop them.

Kolide is the only device trust solution that enforces compliance as part of authentication, and it’s built to work seamlessly with Okta.

The moment Kolide’s agent detects a problem, it alerts the user and gives them instructions to fix it. If they don’t fix the problem within a set time, they’re blocked.

Kolide’s method means fewer support tickets, less frustration, and most importantly: 100% fleet compliance.

Visit kolide.com/macadminspodcast to learn more or book a demo. That’s k-o-l-i-d-e.com/macadminspodcast

Tom Bridge:
As we think about a lot of the pro processes that we have today, we’re in a CICD pipeline kind of world now, whether we want to be or not, and there are some days where I don’t want to be, but here we are. If you want to automate the kind of threat scanning that we’re talking about doing here, if you’ve got some sort of build automation system for your environment, to go to compile your code, to produce the Artifact for distributing your code, how effective is doing your vulnerability scanning during the build process?

Niels Hofmans:
Actually, it can be much more efficient than, for example, doing it after the compilation, for example. Because we have the context of the programming language, we have for example, the package lock files that are being used by the code compiler to see, “Okay, what specific package version are we going to use here for this?” And even up to what is specific, for example, Swiss version or Go version are we using to compile these applications? So, all of that context is already available and it can be easily reused by any other security scanner.
So, something that is also quite popular today is a lot of media attention on our SBOM, so Software Bill Of Materials. And something that we see now happening is that we have a lot of cool security scanners. So let’s say that in the previous step we picked the ideal one for our project, and nowadays, more and more of these tools are being able to export in a standard format that can be used in other steps of your deployment process.
So for example, we have the open source tool [inaudible 00:18:27] micro security, super tool, shout out to the guys and then it can actually export to a SARIF format, and SARIF can then actually be, for example, uploaded into GitHub to there, then do security scanning even after deploying your code to any system that you’re using it on. So, the key is trying to put it into a normalized and standardized format and then re-consume that one to do security scanning and then even up to deployment saying, “Hey, I want an attestation that this piece of code is currently running in production.” Or for example, if it didn’t pause our CICD system, it can’t ever be deployed in production itself. And then we’re looking at the whole of, for example, cosign and all those component bits.

Charles Edge:
So, I feel like this takes us to a pretty nice point where we can kind of shift. We’ve been talking about what can be done before we compile, but after an app’s compiled, then especially if you’re a customer consuming that app, you have a lot less telemetry into, as an example, what Swift packages were used and all the other fun stuff.
So, let’s say a company has hundreds of users who really, really want this sweet Tic-Tac-Toe game that some random developer made. And it comes straight from the CEO, that this business critical tool get installed on every Apple device in the fleet. But our fancy new SOC2 compliance, which we all shook our head about earlier, requires us to run a vulnerability scan on every piece of software before we deploy it now. So, how would you go about consulting with a customer on such an initiative if they haven’t been scanning hosts before?

Niels Hofmans:
Going back to our previous conversation, first, again, looking at the risk profile of application, what amount of effort is worth it to invest in this one and even engaging into a potential political war with the CEO, for example. But the first one would be liaising with the CEO and see, “Hey, what are your requirements specifically?” Like I said, never say no, think along, “Hey, this is hopefully the business reason why you’re trying to deploy this app to your employees.” And let’s think along and let us communicate, “Okay, what are our potential risks that we say, ‘Hey, this could be the business impact if we’re not going to do this exact process.'” It sounds very dry, but it’s more about a thought and getting the mindset right of, “Hey, this is what we’re going to do. This is the reason why we’re doing this and this and this and this is, are the steps forward in our opinion.”
Then we could be looking at things like, “Hey, for example, this developer who is he? Is it a personal account?” Is it for example, an external development company? What is their reputation? Do they have, for example, available security documentation, probably not available online? Do they have a SOC2 ISO, whatever? If not, how is it being deployed? Are we looking at app store? Are we looking at an ad-hoc test flight, we doesn’t pass Apple’s review process of course, which are quite stringent due to their reputation. And the application itself. What can it do? What will it do and what data does it store and process potentially in another country, on another party server, whatever.
And then eventually, we’ll do an overall risk assessment of this, what we think the risk might be. That will dictate how much time we’re going to spend on it as a security company and security team, because we have probably loads and loads and loads of things to do that we don’t want to be spending away for nothing on a Tic-Tac-Toe game.
And then we mostly do quick analysis, for example, a quick static code analysis using, there’s a super cool project online, Mopasef which can be used to scan the application itself, extract some quick metadata out of the application and look, “Hey, these are potential red flags that are being done.” For example, could be something very simple debrief flags, could be tokens or password stored in the application source code. Certain frameworks being used in the application itself, because a lot of information can, for now, still be extracted from the up manifest in the AR replication because yeah, we know a positive format what’s being used to deploy the applications, which are basically zip files.
So, we can easily distract the extracting and then see what’s inside. And then yeah, we can dig and dig and dig and put more time in it as we deem necessary. And then the giggle there is getting those results and converting them into something that is comprehensible to the CEO itself.
This is what we think might happen, this is what is going to cost, this is what we are going to cost in time, for example, and this is what we think you should do, but they should be the key decision maker because also you’re going to shift your responsibility and the mindset to yourself of being the naysayer, but they should pick up the ownership. We are merely the advisor, let’s say. And that’s the culture that you wanted, you’re only coaching and supporting others instead of trying to take the lead in running a security effort.

Charles Edge:
It feels somewhat like the Pardo rule, like, oh, we can isolate 80% of vulnerabilities, but at the end of the day, if TikTok has access to the paste bin or any of these apps, if they load an extension that can access whatever, and on the back end they all, you mentioned JSON, they all seem to just store a whole bunch of data in JSON or Dictionaries, and then pipe it over to rest in points. And when you’re posting that, you can let’s say compress it all into a proto buff and then you have no telemetry into what’s going over it.
So, it does feel like you can just go deeper and deeper and deeper. And that extra 20 or 10 or 5%, it feels like there’s a J curve to the cost of doing that analysis. But then, of course, version two of that Tic-Tac-Toe game comes along and now they’ve actually included a really rad feature where they can go find photos like a lens, but without the paywall. And I guess who knew Tech Tic-Tac-Toe could be so expansive. So now, I guess, we’re going to need to automate our scanning for every version possible. So now it’s even more important with the whole build train thing. So is that even possible, I guess

Niels Hofmans:
No end of conversation.

Charles Edge:
Yeah, I guess at that point, you what punt to your ZTNA or your network scanning, would that be where you’d take a customer who wants further telemetry beyond all that?

Niels Hofmans:
So if you look at it purely as, for example, a techy something, what I would do is take for example, take the previous risk posture, put it into a serializable or just a standard format, put it into a GI repo directory storage there for safekeeping, for example, last time, believe you this date, this contact person, whatever. And then we’re going just going to do a new quick risk assessment on the new version, see what changed. So for example, there could be a change lock from the vendor itself in case we don’t have a change lock. We’re going to manually unpack and the binary itself to see what changed.
And then we’re going to do a whole risk decision again, for example, new feature that might warrant a new penetration test, for example, that we’re going to do an application itself. Or there could be as we have a simple graph that we’re using to extract or using to extract all your rails from the application itself, David, if there’s a new one, this will raise some questions and for example, using a simple web proof in a GitHub that might take it a Slack message to using, Hey, look into this change or this and this is potentially interesting.
So really I would try to get it into a process itself, try to put it into a standard format and then try to looking at what changed since the last time that we run it and then do a risk decision based on those. It’s not perfect, but the main focus is we need to get speeds to still run along with the business process itself and then try just to make it an iterative process. There are a couple of solutions specific ones that you could use, but it’s difficult to say whether it will work or not in your specific situation. That doesn’t mean gist of it.

Charles Edge:
Yeah, I guess the Pareto rule applies to cost of the tools in addition to cost of the labor, right? Because those tools that you’re mentioning are quite expensive in my experience. So I guess you mentioned test flight and we’ve talked about the app store, then there’s just installing straight software packages and using something like install enterprise application from MDM apps from the app store, though were kind of being taught by marketing can be trusted, or maybe they can’t, I don’t know, but the app store isn’t really the only package manager on our computers. I guess we can have an open conversation about tools like CAN or languages like Go Pearl, PHP, Ruby Python with their package managers, or maybe even tools like Home Brew with larger atomic operations where they’re running these larger recipes in the background. Are people monitoring just amongst all of us, have you seen people monitoring for what’s installed via those and what version they’re running, what those objects can kind of access outside of the machine?

Niels Hofmans:
So this is going to be a very interesting conversation. I think this part, this portion, because it’s a major blind spot in a lot of enterprises and a lot of commercial detection software that’s currently being used on the market. So the ones that for example, are typically picked up are going to be the typical DOT apps in your certification. Sub-directory could be your locally installed button or got forbid, your HTTPB version installed in your microwave, which is rigging a CV that needs to be fixed, dictated by security team, but actually a lot of the other ones, so for example could be, it could be any package installed by BREW could be, for example, specific binary that you installed using Go installed. Those are typically not picked up by the most common commercial vendors on that side. And that’s a major risk. That’s something we know.
We’ve been seeing the same thing for years and years with the Windows subsystem for Linux. What we, typically, have is a heavily protected Windows endpoint. We completely bare unprotected Linux Kernel living inside of it, which yeah, nowadays with WSL2 is directly connected with the Windows Kernel. So, it’s quite an interesting attack target, and I don’t know any security vendors yet that, for example, protect the WSL2 Kernel, or that environment itself. So it’s a major blind spot currently.
Luckily what we’re seeing is that there are a lot of interesting moves to better help protect against this. So, we know that there’s a lot of feature requests with EDR endpoint detection and response vendors, for this one.
No, I’m, me being one of the demanders there and hitting their website up every day. But on the other side, we also see a bit of community effort. For example, the Go [inaudible 00:30:07] check that exists to see in this specific project what is being used that is vulnerable, or for example, that could be other initiatives that could be implemented in OOS query, let’s say, to say we’re still going to scan for BREW packages, but then the question is who’s going to link the BREW version to, for example, the national vulnerability database, which is a sore in the eye to look at, sorry for the gas maintaining it, but, it’s a data problem.

Tom Bridge:
That’s my neighbor.

Niels Hofmans:
We’ve talked about it a few times on the pod.

Tom Bridge:
It’s hard to look at, but there’s a lot going on there.

Niels Hofmans:
Yeah, yeah, for sure, for sure.

Marcus Ransom:
And it’s also the word, context, that you mentioned before, is something that’s really important there. It’s not just we have this particular binary on the machine. Do you have that particular binary that has a vulnerability on a system that is able to be exploited with that vulnerability and all of a sudden the ability to detect and deal with that becomes incredibly complicated? And I’ve seen the approach to that being not allowing developers and engineers to use any of those package managers, but then that has an enormous impact on efficiency…

Charles Edge:
Productivity.

Marcus Ransom:
Do the work that they need to do, and see a lot of time being bogged down in security having incredibly valid concerns about those tools, but at the same time, business needing to run.

Charles Edge:
And Furthermore, I find that if you take away CPAN or BREW or some of these tools from software developers, they magically learn how to bypass your other security systems really quickly. And now you’re just…

Marcus Ransom:
Life spins away.

Charles Edge:
Right.

Marcus Ransom:
So, your code base is now sitting on their completely unsecured Mac that they’ve, yeah, and all of a sudden that’s not getting any vulnerability scanning.

Niels Hofmans:
Makes me think of it. I think AppleScript as an JavaScript engine nowadays. So perhaps they could even use that one to just start doing funky stuff as well.

Marcus Ransom:
I should probably check on that tomorrow. Yeah.

James Smith:
This episode of the Mac Bins podcast is sponsored by Data Jar creators of datajar.mobi, a cloud-based managed MDM solution that redefines Apple device management developed from the ground up by Apple admins, for Apple admins, datajar.mobi is the first solution to truly extend the capabilities of Jamf Pro. The undisputed leader in Apple device management. Datajar.mobi supercharges Jampro through a managed MDM service that delivers simplified zero-touch workflows, fully automated patch management, centrally managed EDR, and a scalable multi-tented view with centralized reporting for global and distributed fleets. Designed to provide IT teams with the best of both worlds, we have developed a true MDM as a service platform for Apple admins that is fully managed and scalable, but can also be controlled through a rich but simplified web interface, backed by the unmatched experience of the award-winning Data Jar engineering team. Is no surprise datajar.mobi is consistently ranked in the top 10 highest rated solutions in the G2 grid for mobile device management. Want to learn more? Come and say hi in the Data Jar channel of the macadmins, Slack, or visit us at datajar.co.uk/macadmins podcast.
Thanks so much to our friends at Data Jar for sponsoring the Macadmins podcast.

Tom Bridge:
One of the things that we haven’t really talked about here is dependencies, because it’s rare these days that software is built entirely from the binary that it is constructed out of. It is not entirely unexpected for imports to happen, for modules to be imported, for node packages to be included for Cocoa Pods to be engaged. All of these different solutions here are great ways of taking other people’s code and putting it in your code, with all of the challenges that can come with, there. What guidance do you have for folks around this kind of supply chain dependency hell, that we’ve just described?

Niels Hofmans:
Yeah, it’s going to be a big one, but first of all, look at the tooling that works most natively in your current situation. So Go, thanks again. I’m going to keep repeating on that one. And then try to again, focus on the standard format that you could consume from others. So there could be, for example, using, sorry for hitting up on Go again, but Go Check, that will then do transitive dependency, checking on all dependencies of dependencies of dependencies, whatever, and then try to on your term, pause that on again.
So for example, we know that GitHub has been appointed as a CV numbering authority. So potentially, that could be used to feedback your own CVs that are reported back into the whole system again. And then ideally as a [inaudible 00:35:12], everyone as a home in the world would be happily producing S-bombs that are done, consumed by each other to check, “Hey, what are using? What component are you using?”
And not having to phone up a vendor asking, “Hey, were you actually impacted by Log4j? But automatically knowing because you’re already consuming their S-bombs from them, for example. But let’s just say that packaged lock files already are a huge help in their regards of being pinning down what exact versions that we’re using. And in the end, signing those and passing those on to the next steps in the workflow, those are already a major help.
So again, look at the tooling that works best in your situation. Put up your own expectations. So for example, package lock files, being able to resolve transitive dependencies and being able to link those to CV numbering authorities. You don’t have to do it yourself, but use a tool that does. And then being open and transparent enough to pass that on too. For example, your rent customer.

Charles Edge:
That is an interesting point about trying to pick something that’s native. I feel like five or 10 years ago we were starting to hear guidance that, “Well, it’s a microservice based world.” Doesn’t matter if people are writing in let’s say PHP, LAL, or no JS or whatever, and can have two or three Scrum teams doing things however they want to do it. But if you are in that situation, then all of a sudden you are trying to manage all these different tools to not only secure, but automate the deployment of and management of some of sometimes all that codes.
So, it’s almost contrary to the guidance previously, and I don’t feel like I’ve heard that a lot from people who manage larger dev organization. It’s like, “Oh, well let’s try to centralize on one language again.” Yeah, I know it’s all a bunch of lambdas or whatever that’s connecting the software, but let’s try to keep it in one language, or at least one overarching platform so that it makes sense.

Niels Hofmans:
And we have to recognize that not everyone’s a Netflix. We only have so much time, we only have so much money. And most of the time, even within the smaller security teams, everyone’s already optimizing their own time and cost to be able to cope. So, that’s why we just have to make smart decisions to save ourselves, sometime.

Charles Edge:
I like that phrase, optimizing their own time to cope because none of us ever have enough time, do we?

Niels Hofmans:
Amen.

Marcus Ransom:
Thursday-and-a-half, Thursday-and-a-half is the solution to everything. So, one of the complaints a lot of pundits have had about iOS is the walled garden, the closed app store model, and how that limits choice for users. But the other side of that is it makes it a lot easier for device security. Unless a device is Jailbroken, you at least know where the applications are coming from, so you can target that specifically. But there’s been a lot of talk in Europe, especially, recently about convincing Apple to open up iOS to non-AP store apps. So that makes application security a whole different challenge for organizations. Does that mean a new yacht for companies like yours now that you have to start offering scanning of absolutely anything on iOS?

Niels Hofmans:
Yeah, but it’s a very valid concern and it’s, for example, something that already exists in years and years on Android, which for example, the Android store, et cetera. So hey, a cool new place to deploy official or nonofficial pirate modified applications and yay, we can finally watch YouTube without ads, supposedly. But yeah, in the end, it’s crazy what the risk profile is of those applications. Anyone can push any application as long as you grab, for example, the name space first of an official game, let’s say, then deploy it out and everyone at the company is consuming a third party.
Yeah, I call it [inaudible 00:39:25] remote code execution as a service. So, it certainly is a valid concern and let’s hope. And yeah, most often it is, as with most things that Apple rolls out are rather well thought out, and hopefully we’ll have a method to disable those external app stores. Just as for example, that some EDM configurations might even disallow the Apple app store and only push out their own application in a white list fashion. Let’s just hope that we will be able to disable the external app stores to still profit from the security review process that request string. But yeah, for the good reason in the security context

Speaker 6:
Here at the Mac admins podcast, we want to say a special thank you to all of our Patreon backers. The following people are to be recognized for their incredible generosity. Stu Bakka, thank you, Adam Selbe, thank you. Nate Walk, thank you. Michael Tye, thank you. Rick Goodie, thank you. Mike Boylan, you know it, thank you. Melvin Vivez, thank you. Bill Steitz, thank you. Anu Storville, thank you. Jeffrey Compton, M. Marsh, Stu McDonald, Hamlin Crusin, Adam Berg, thank you. AJ Petrepka, thank you. James Tracy, Tim Pert of Two Canoes, thank you. Nate Sinal, Will O’Neill, Sebnash, the folks at Command Control Power, Steven Weinstein, Chet Swarthout, Daniel McLaughlin, Justin Holt, Bill Smith, and Weldon Dot. Thank you all so much and remember that you can back us if you just saw head out to patreon.com/admpodcast. Thanks everybody.

Marcus Ransom:
So thinking about distribution, so we know that it’s, well, it’s locked down in iOS, but there’s been a lot of convergence with Mac OS becoming more and more like iOS. So how have you found Apple’s recent approach to MAC OS system security with system integrity protection, bringing notarization, sealed system volume PPC, has that made life more difficult or easier for application security in Mac os? How have you seen Mac OS application security change with these new technologies?

Niels Hofmans:
So quite the awesome thing to see is the major advancements because I think we can say that those are major security advancements made from Apple site. And the amazing thing is that you can see that architecturally speaking, those things have been brewing for years and years and years, right before we were even figuring it out, or thinking about those things. And I think there’s quite some positive changes ongoing. Of course, there are some hurdles. So for example, there were some security things with the T2 chip or some other things, or we know that PTC sometimes has these bypasses that are possible, for example. But generally speaking, we’re seeing large strides on a positive side from Apple itself, and that’s quite positive and quite nice to see.
Not having to think about, for example, certain low levels attack or for example, the whole trust scenario of how can I ensure that, for example, an application being run on an iOS device, whether it is trusted by the user itself is just so simple. Because for example, you have the user encryption key, you have the trust root key, and for example, the secure enclave of the iOS device itself just makes things so much easier for me as a security enthusiast and a security user myself. I could say that we’re moving in the right direction and the recent architectural changes from Apple, et cetera are quite positive in my opinion.

Tom Bridge:
And we also get things like the new attestation service that you can build using ACME Cert profiles to essentially, “Hey, is this device, in fact, genuine? Is this device, in fact, not Jailbroken?” And that’s going to give you a lot more peace of mind that’s present there.

Niels Hofmans:
Yeah, for sure.

Marcus Ransom:
I think it’s great for Mac admins to hear security professional like yourself say that because we’re often, we’re constantly told this by Apple, that these changes that have created absolute chaos for what we do and how we respond to these and how we manage them, but to get that validation that this, it’s working and there’s a really good reason that this is being done. It’s not just Apple deciding to throw the toys out of the pram just for the sake of it, which at times it can seem. But getting that validation that what you are seeing is a real benefit in security and something that what we’re all wanting to do is make life better for our users.

Niels Hofmans:
Yeah. And sometimes even the devil’s in the details, for example, the SEAL system volume was a requirement for currently doing the rapid security response, since that depends on having signed volumes in separate, yeah, caches let’s say, that are then turned on or turned off depending on the usages itself. So sometimes for us as a users, since we of course can’t foresee what the future might bring for Apple itself, sometimes we’re very narrow-minded in seeing, “Hey, why are we getting this specific change, which will only cause us problems on the short-term while we don’t see the full picture on the long-term.
Not to say that they are not going to make any bad decisions or bad implementations. I think we all as a maxism, can agree that are a couple that we could pull a beer on, let’s say. But more in the long term, we often don’t see the big picture and it’s going to be improvement probably.

Charles Edge:
It’s an interesting point, the be patient either there’s something else coming. I think with sip, a lot of these other things were in the works when it was rolled out and a lot of us were annoyed about certain aspects or notarization or, et cetera. But then as the fuller picture began to unfold, I do feel like security postures haven’t necessarily changed to embrace this movement of the footprint of threat, but it’s definitely harder.
And so, that needs to move to the next, an attacker needs to move to the next much more complicated, much more savvy attempts to get at things. No longer can you just have a little webpage that has a profile that proxies traffic and steals stuff. There’s all of these things are little building blocks to a much more comprehensive security posture on the OS side, which is pretty rad. And speaking of beer, since you mentioned the word beer, we have a bonus question today, right, Tom?

Tom Bridge:
We do have a bonus question, and I love this bonus question because it’s a hard one. So, our bonus questions usually aren’t bullying, but we’re going to make one today. So Belgian waffles or Belgian beer?

Niels Hofmans:
I’m going to drop a bombshell, but Belgian waffles often our tourist trap. So for everyone traveling to Belgium, I don’t recommend to buy them. The smaller the place, probably the tinier the space, the better the waffles, they’re going to be, but no, I’m going to pick the beer here. Beer, like for example, yeah, I think there’s a various course on the [inaudible 00:47:06], for example, Duggle. There’s certainly beers that I can appreciate myself. I’ll pick the beers.

Tom Bridge:
Yeah, I was going to say, I will also take the beers. I am not ashamed of taking the beers. I’m 100%, going to take the beers, but I’m going to take the American version of the Belgian beers. So my friends at Brewery Ommegang, up in Cooperstown, New York, their Three Philosophers is my favorite Belgian style beer. But I was going to say, it’s hard to resist a good Duggle, when one presents itself. So… Marcus, how about you?

Marcus Ransom:
When I was a drinker, Stella Artois was my poison of choice for beer. And now that I know, I can’t say Belgian waffle, so I guess I’m going to have to go for a fries with mayonnaise, or something like that.

Charles Edge:
All right, I’ll take French.

Marcus Ransom:
Yeah.

Niels Hofmans:
Just don’t say french fries. There’s a difficult…

Marcus Ransom:
No, no.

Charles Edge:
And I’m not going to use one of the dozens of trappists that I’ve grown to know and love. Instead, I’m going to say Belgian beer waffles. So, let’s just take it all and wrap it into wine.

Tom Bridge:
Are you cheating? Is that an…

Charles Edge:
I am totally cheating and yeah…

Marcus Ransom:
Did your bullying escape at sandbox, Charles?

Charles Edge:
You know, bullying can exist as true, false, or nil. So, I’m picking the third rail here, but I’ll…

Marcus Ransom:
Is this the puzzle of contents from previous time or was…

Charles Edge:
I’ll include a link in the show notes for a Belgian beer waffle and just hopefully someone will take joy out of that.

Tom Bridge:
Fantastic. Niels, thank you so much for joining us this week. If folks want to learn more about the work that you guys do or find you online, where should they go?

Niels Hofmans:
Sure, they can check out the website of intigriti.com. I also have a GitHub page, where I try to also, a couple of interesting projects and that’s hosted on [inaudible 00:49:04].com and that will redirect to the GitHub one. Thanks for having me and pleasant talking.

Tom Bridge:
Yeah, yeah. And for those listing along at home, all of these links and other links that we’ve talked about today will be in the show notes, so you can find out more about this and other items as you go through the rest of your research. So Niels, thank you so much for joining us. It was a pleasure talking with you today. I hope we get the chance to talk with you again.

Niels Hofmans:
Likewise. Thanks guys.

Tom Bridge:
Well, wonderful. And this has been another great episode of the Macadmins podcast This week we were sponsored by our friends at Kandji and Kolide, and our friends at Data Jar. And of course, we’ll see you next week. Bye everybody.

Charles Edge:
See you next time.

Marcus Ransom:
See you later.

Speaker 6:
The Macadmins Podcast is a production of Macadmins Podcast, LLC. Our producer is Tom Bridge. Our sound editor and Mixing engineer is James Smith. Our theme music was produced by Adam Kodiga the first time he opened GarageBand. Sponsorship for the Macadmins Podcast is provided by the macadmins.org Slack, where you can join thousands of Macadmins in a free Slack instance. Visit macadmins.org. And also by Technical Evolutionary, LLC. Technically, we can help. For more information about this podcast and other broadcasts like it, please visit podcast.macadmins.org. Since we’ve converted this podcast to APFS, the funny metadata joke is at the end.