@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@brandon220 said in AzureAD and shares:

Here is an example from the FFIEC Cybersecurity Assesment Tool:

The more OSS you have, the lower your score will be.

I'm not defending or even sure this is what they are talking about, but they may be looking at the risk of the licensing. It can be tough to keep track of all of the licensing of open source tools and making sure you comply with them.

But, honestly, not nearly as hard as the risks of anything else. And "can be" should never be a legitimate factor. ONce we go down that path, we could list unrealistic risks for forever.

Right, like I said I'm not defending them. Just trying to look at it from all angles.

What people never consider is that closed source licensing COULD still require in the EULA that you comply with GPL of your own code simply by using the closed source product Cloud source EULAs can pretty much carry any risk imaginable. They don't, but they could.

Yeah definitely true. I don't like closed source at all. I mean if I need the tool I'll buy it but I'd rather use a open source tool.

I've seen a lot of people thought that think they can just do whatever since it's open source and it doesn't matter. AGPL is pretty strict and there's a lot of popular tools written with that license.

In most cases, it's people thinking that they can just use the code without following the license. Technically, a far bigger risk with closed source under the same conditions.

In general yeah, but the GPL police are fierce. I work with a guy who's old company was going to be sued for not including the simple configs they wrote along with the distribution.

Yeah, although now we are talking product firms, not operations. The affect on operations is generally minimal.

Yeah true, but that's similar with proprietary also, most people don't get caught. You still have to comply though. It can be a lot of work to ensure you're in compliance. Like when software decides to change licenses between versions.

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@brandon220 said in AzureAD and shares:

Here is an example from the FFIEC Cybersecurity Assesment Tool:

The more OSS you have, the lower your score will be.

I'm not defending or even sure this is what they are talking about, but they may be looking at the risk of the licensing. It can be tough to keep track of all of the licensing of open source tools and making sure you comply with them.

But, honestly, not nearly as hard as the risks of anything else. And "can be" should never be a legitimate factor. ONce we go down that path, we could list unrealistic risks for forever.

Right, like I said I'm not defending them. Just trying to look at it from all angles.

What people never consider is that closed source licensing COULD still require in the EULA that you comply with GPL of your own code simply by using the closed source product Cloud source EULAs can pretty much carry any risk imaginable. They don't, but they could.

Yeah definitely true. I don't like closed source at all. I mean if I need the tool I'll buy it but I'd rather use a open source tool.

I've seen a lot of people thought that think they can just do whatever since it's open source and it doesn't matter. AGPL is pretty strict and there's a lot of popular tools written with that license.

In most cases, it's people thinking that they can just use the code without following the license. Technically, a far bigger risk with closed source under the same conditions.

In general yeah, but the GPL police are fierce. I work with a guy who's old company was going to be sued for not including the simple configs they wrote along with the distribution.

@scottalanmiller said in Ansible Agent Option?:

@stacksofplates said in Ansible Agent Option?:

You need one "agent" which is the SD-WAN client and that's it. The other way you will have most likely more than that because you will want some time of minor logging, monitoring, remote support like RDP, etc.

Most of that traffic is outbound, though. In theory, with something like Salt, you can have zero inbound ports for IT. Sure, applications might need something, but there will never be a way around that. But no additional ports opened for IT use. Or if there is, they can be opened ad hoc and closed as soon as they are not used.

A lot are, but a lot of new ones aren't. Monitoring tools like Prometheus scrape clients and logging tools like Loki scrape logs in a similar way.

My point is I think it's much easier to take the 10 minutes to write the automation to set the client up the way you want and only allow access on that network from where you define. Then it doesn't matter what tool you decide to use. And when new ones come out or old ones are deprecated it's much easier to adapt.

Yeah it's obviously bad to treat it like a LAN but if you stop using tools just because it can be treated that way you are sometimes stopping yourself from doing some really interesting and helpful things.

Not aimed at you, just a point in general.

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@brandon220 said in AzureAD and shares:

Here is an example from the FFIEC Cybersecurity Assesment Tool:

The more OSS you have, the lower your score will be.

I'm not defending or even sure this is what they are talking about, but they may be looking at the risk of the licensing. It can be tough to keep track of all of the licensing of open source tools and making sure you comply with them.

But, honestly, not nearly as hard as the risks of anything else. And "can be" should never be a legitimate factor. ONce we go down that path, we could list unrealistic risks for forever.

Right, like I said I'm not defending them. Just trying to look at it from all angles.

What people never consider is that closed source licensing COULD still require in the EULA that you comply with GPL of your own code simply by using the closed source product Cloud source EULAs can pretty much carry any risk imaginable. They don't, but they could.

Yeah definitely true. I don't like closed source at all. I mean if I need the tool I'll buy it but I'd rather use a open source tool.

I've seen a lot of people thought that think they can just do whatever since it's open source and it doesn't matter. AGPL is pretty strict and there's a lot of popular tools written with that license.

@scottalanmiller said in AzureAD and shares:

@stacksofplates said in AzureAD and shares:

@brandon220 said in AzureAD and shares:

Here is an example from the FFIEC Cybersecurity Assesment Tool:

The more OSS you have, the lower your score will be.

I'm not defending or even sure this is what they are talking about, but they may be looking at the risk of the licensing. It can be tough to keep track of all of the licensing of open source tools and making sure you comply with them.

But, honestly, not nearly as hard as the risks of anything else. And "can be" should never be a legitimate factor. ONce we go down that path, we could list unrealistic risks for forever.

Right, like I said I'm not defending them. Just trying to look at it from all angles.

@brandon220 said in AzureAD and shares:

Here is an example from the FFIEC Cybersecurity Assesment Tool:

The more OSS you have, the lower your score will be.

I'm not defending or even sure this is what they are talking about, but they may be looking at the risk of the licensing. It can be tough to keep track of all of the licensing of open source tools and making sure you comply with them.

@Dashrender said in Ansible Agent Option?:

@scottalanmiller said in Ansible Agent Option?:

@Dashrender said in Ansible Agent Option?:

@stacksofplates said in Ansible Agent Option?:

@Dashrender said in Ansible Agent Option?:

@stacksofplates said in Ansible Agent Option?:

@Obsolesce said in Ansible Agent Option?:

I don't see ZT as a solution to this, I see it as an unnecessary workaround.

I don't see it that way. Agents were created when things like SD-WANs didn't exist. Now, all of you devices can connect easily no matter where they are. It's actually easier to implement paradigms like zero trust when the systems are connected that way.

Though, as Scott said earlier - using SD-WAN tech requires a lot more work to segregate the clients on that SD-WAN from each other.

With an agent - you don't worry about that at all. Instead you put all of your concern on the open port for the centralized server.

Yeah you do. You need to separate them by server. So you need a different master for each network. So you have multiple central servers that are each their own cert authority for the app.

OK, that's still likely easier to manage and deal with compared to the setup and config of the SD-WAN stuff.

and in a case like Scott's - I'm guessing he's just spinning up new VMs on his Scale - or someplace like Vultr.

He's saying you do one SD-WAN + one Master (or two) per network / customer. So still an SD-WAN, but no risk of "bleed over".

Yes I get that - but managing that SD-WAN is still more work than managing the agent on each end device. As you mentioned before, you have to setup the firewalls, etc on each endpoint with SD-WAN, not something you have to worry about (in this context) for the agent.

I don't really see it that way but we aren't going to agree on everything. The firewalls need set up regardless, and it would be automated through whatever your tool is.

You need one "agent" which is the SD-WAN client and that's it. The other way you will have most likely more than that because you will want some time of minor logging, monitoring, remote support like RDP, etc. I mean it solves a lot of things with just one client.

@scottalanmiller said in Ansible Agent Option?:

@stacksofplates said in Ansible Agent Option?:

@Dashrender said in Ansible Agent Option?:

@stacksofplates said in Ansible Agent Option?:

@Obsolesce said in Ansible Agent Option?:

I don't see ZT as a solution to this, I see it as an unnecessary workaround.

I don't see it that way. Agents were created when things like SD-WANs didn't exist. Now, all of you devices can connect easily no matter where they are. It's actually easier to implement paradigms like zero trust when the systems are connected that way.

Though, as Scott said earlier - using SD-WAN tech requires a lot more work to segregate the clients on that SD-WAN from each other.

With an agent - you don't worry about that at all. Instead you put all of your concern on the open port for the centralized server.

Yeah you do. You need to separate them by server. So you need a different master for each network. So you have multiple central servers that are each their own cert authority for the app.

You can definitely do that, but that's upping the complexity each time. Not that spinning up any of these tools (SS, Ansible, Chef, Puppet) in a LXC container with low resources isn't easy and easily repeatable, you can make that pretty low overhead. But definitely more complexity than a single "master pool".

Right but you have a single system tied to each network which is what you said earlier that you specifically didn't want.

I back up with Borg to a Linux server. I was using Urbackup but Borg is so simple. I'll probably end up switching to Restock because their refactored code is supposedly faster than Borg now (used to be the other way). I also have a bias to things written in Go

That server then backs up to Crashplan.

Like for example adding rd.break at boot.