2 ms·

I really appreciate the reply - everything you mentioned basically confirms my suspicions and gives us some good pointers to look at next. Is my interpretation

I really appreciate the reply - everything you mentioned basically confirms my suspicions and gives us some good pointers to look at next. Is my interpretation of your message correct in that, even in the HTTPS/TLS-based agent approach, that mTLS might be hard to achieve in practice? I am trying to guage if the absense of mTLS would be something that would frequently be nit-picked in security reviews. My first-hand experience reviewing vendor agents (Newrelic, Datadog, AWS SSM, Azure Connected Machine etc) tells me probably not as its generally not default-required in those agents, but just looking to crowd-source some other opinions. Another value prop of TLS-based agents appears to be that it allows customers to potentially keep the credentials to systems we are automating inside the agent config, as opposed to us needing to store those credentials in our SaaS platform. Wondering if you have any thoughts on this topic as well. Lastly, are you aware of any open-sourced python-based agents that could serve as a good reference point in terms of best practices? Thanks again!

xyzzy123 1y ago
Thanks. What I've seen is that organisations are focused on process compliance, not technical security. As long as people can tick the boxes in standard supplier assessment forms (which you can do with plain TLS, not even mTLS), you can be successful. The question is, does the product do something that people desperately want? They will find a way to fill out the forms / justify the use of the product if it does. It can actually make the process more difficult if you are very different from your competitors in your security strategy, people have to expend effort to understand why you are different. For mTLS specifically, it would be great as an option / thing that customers can configure if they want to go above and beyond, but may cause difficulties for many customer(s) as a requirement. As you observe, comparable vendors are generally plain TLS with a license / token / secret.

xyzzy123 1y ago

Thanks. What I've seen is that organisations are focused on process compliance, not technical security. As long as people can tick the boxes in standard supplier assessment forms (which you can do with plain TLS, not even mTLS), you can be successful. The question is, does the product do something that people desperately want? They will find a way to fill out the forms / justify the use of the product if it does. It can actually make the process more difficult if you are very different from your competitors in your security strategy, people have to expend effort to understand why you are different. For mTLS specifically, it would be great as an option / thing that customers can configure if they want to go above and beyond, but may cause difficulties for many customer(s) as a requirement. As you observe, comparable vendors are generally plain TLS with a license / token / secret.