I shall join the ranks of the idiots then, cause the question "Are the certificates on these IoT devices centrally managed?" makes no sense to me either, just not because I wouldn't know what certificates are.
Centrally managed? Like are these devices enrolled into some centralized management system, and so is the question whether that system also manages the OS root cert store? (And would have been followed up with whether it blocks TLS traffic that it's unable to intercept?) Or is it maybe whether the vendor's applications deployed to these devices use that or carry their own?
But then I read on, and PKI and HTTPS comes up. Is centrally managed then referring to PKI being a centralized trust system, and so is the question really "are you using CA issued domain certs"? Why the contrived phrasing then?
And then there's a mention of an internal domain name. Internal as in private? Sounds a bit suspect that the guys who don't know what a certificate is would have a private DNS with a private CA to boot, but it sure would be centralized alright.
I think it's inquisitive that the first common point reached was HTTPS: yes/no? -> yes. But then even that was seemingly a bit too new info: in the portrayed discussion it is first also asked whether HTTP is in picture. This makes me question, just what did the author even know about these devices when they prompted their centrally managed certificates question.
Maybe a better question at that stage would have been, "So, how do these devices communicate, and what to?", letting them explain it in their own terms first?
In a normal OS under normal conditions, the certificate store is centrally managed by the OS vendor. The answer then is “yes”.
But it's possible to install a certificate of your own in which case the answer is probably “no” because when it expires you're going to have to to every one of those machines and install the replacement.
Or imagine an embedded computer that doesn't even have an OS. Then the certificate store just has whatever the developer put into it when they built the image. Again the answer is “no”. If you're lucky you can still rebuild the image and reflash the devices even though the engineer who did the work was fired as a cost–cutting measure. If you're not lucky then that VP’s cost–cutting has actually added a lot of cost.
> For Security Professionals (us): Stop being gatekeepers and start being enablers. Put down the "How do you not know this?" attitude and pick up the "Let me explain why this matters" approach.
Eeeehhhh… gatekeeping is, IMO, not quite the right term.
On the one hand, gatekeeping is restricting access until conditions are met, regardless of how spurious and irrational those conditions are. And usually, despite some pretty insane conditions. Questioning the fundamental competency of someone who ought to know even just a little better is challenging why they aren’t already possessing access, not preventing access in the first place.
On the other hand, most people in the IT industry love to talk about all the little shinies they are obsessed about. So while they may not be the best teachers in the first place, tickle their passionate shinies hard enough and they will talk your ear clean off, down the hallway, drop it through the lift and have it staggering bloody and beaten onto the sidewalk outside before you can get a word in edgewise. So getting people in IT to be advocates for the work subjects they are passionate about is not the problem - it’s training them how to deliver that information effectively to someone not in the know and not initially passionate about it.
On the gripping hand, there are plenty of people in almost every industry for whom ”How do you NOT know about this core component of your job??” is a very valid criticism to lob with great enthusiasm at them. A verbal shock like this can be very useful for disturbing a person out of their complacency, especially if they already see themselves as an SME. The real trick is following that statement up with something that can truly inspire and encourage them to willingly reach for competency in that component.
Unfortunately a lot of documentation and tooling for TLS apis are horrible.
For example when working with Apple's Network.Framework, I have to drop to C and use functions like "sec_protocol_options_add_tls_application_protocol". Maybe the new beta framework is better.
Or if I want to get a certificate hash on the command line in a usable format,
I'd have to run
"openssl x509 -in server.crt -noout -fingerprint -sha256 | sed 's/://g' | cut -d= -f2"
Networking and security is still a dark art and it shouldn't be.
Great read! The analogy between physics and infosec is spot-on—both rely on understanding fundamental principles that are often overlooked. The "AES256-over-HTTP" anecdote is both hilarious and terrifying, highlighting how abstraction can hide critical gaps. As a dev, I see similar issues when devs prioritize speed over security basics. Curious—what’s your go-to approach for teaching devs about PKI or mTLS without overwhelming them?
>Now, I'm not blaming developers. Modern software engineering is built on abstraction layers, and that's actually amazing! We've gone from assembly language to high-level frameworks, from bare metal to cloud-native platforms. A developer can slap a @RestController annotation on a Java class and magically have an HTTPS endpoint without knowing anything about TLS handshakes or certificate chains.
Well, you should blame the developer if they don't know the basics of computer science (TLS handshake being the basics)
A developer can slap a @RestController annotation on a Java class and magically have an HTTPS endpoint without knowing anything about TLS handshakes or certificate chains.
Is a bad thing. Most people only skims the surface of what they use in daily life. Obviously there are so many things that it is hard to do otherwise. But this job is one time only...
Which is why AI seemingly replacing junior engineers, because AI does the same thing, faster and cheaper...
Meanwhile, I as an engineer, see less and less appreciation and importance in my organization about "knowing" these stuff.
very good philosphy, near the end author says "Think of yourself as a physics teacher, not a physics textbook."
Very good.
As for appearing surprised that many people do not care, so it is.
Everyone has a relative that after 30 years still doesn't know how to use the airco controls?
I read somewhere it all follows some sort of gaussian/normal distribution, like in 11 peole there might be 1 knowledgeable, 2 interested, 5 pretending to listen, 2 bored, 1 sneaking out.
Sometimes it's you or me who sneaks out.
the underlying connection the author is making between physics and security is knowing the low level laws governing the systems you are dealing with, or at least being aware of them. if anything the functional programming bit could have been left out.
The low level laws "governing" security are just procedural rules made up by humans. There could be a thousand ways to "secure" something but the author is just following convention here.
The axioms of functional programming and physics are not arbitrary conventions. They are fundamental to reality.
At its foundation modern security is based on ideas from information theory and cryptography that were discovered, not invented. Arguably just as fundamental as the postulates of general relativity or quantum mechanics.
Doesn't change a thing. All things are derived from fundamental principles.
IT Security is an arbitrary methodology derived from fundamental principles, but it doesn't change the fact that it's arbitrary.
I can make up dozens of ways to make something "secure" that doesn't follow convention. Why isn't he using biometric data like saliva DNA testing to verify identity? And why are they using a channel that anyone can peek at? Send the signals and credentials over a blinking laser light and therefore we know if the laser is disrupted we have someone trying to peek at the encrypted signal.
See what I'm saying, I can arbitrarily come up with dozens of ways to make things not only just as secure, but MORE secure. IT security is mostly memorization of convention. These conventions are derived from fundamentals, they are not principles themselves. There are thousands of orthogonal methodologies to achieve the same level of secureness but the set we use for IT are just an arbitrary selection out of an infinite amount of possibilities.
but that's not the analogy the article was making at all! it was making an analogy with using technology based on underlying physical principles, where you could either be cognizant or ignorant of those principles, and similarly you could use something like https while either knowing or not knowing what the lower level pieces it relied on were.
Yeah and I'm saying it's a bad analogy. Because the principles of security are made up. They aren't fundamental. They are arbitrary and they exist by convention.
Usually concepts that are arbitrary I wouldn't call "principles" because they aren't principles. Just convenient rules to follow. A principle is much deeper.
I think that technical people tend to see their area of expertise the most fundamental one, from which everything else derives.
This guy specialized in security and so he thinks that the concepts that he learned underlying everything, and everything else is just application.
But he's making the same mistake as everyone else. Everybody has gaps in their knowledge, it's just that he chooses to talk down to people who have their in their knowledge in _his_ area of expertise. Physicists do this a lot (I should know: I trained as a physicist so I know a lot of physicists). "Physics is really everything, everything else could be deducted from physics in principle, so no point spending time thinking about it". He carried this attitude into the next area of expertise he learned.
I'm with the project manager. "How does the gorb fleem the leemaflop?" Don't know, don't care, you do your job and I do mine. Time is finite and I'd rather spend my time on things I find intellectually stimulating, not IT security. The irony is, if everybody could reliably answer those questions, he wouldn't have a job. I find the lack of understanding quite disgusting frankly.
I shall join the ranks of the idiots then, cause the question "Are the certificates on these IoT devices centrally managed?" makes no sense to me either, just not because I wouldn't know what certificates are.
Centrally managed? Like are these devices enrolled into some centralized management system, and so is the question whether that system also manages the OS root cert store? (And would have been followed up with whether it blocks TLS traffic that it's unable to intercept?) Or is it maybe whether the vendor's applications deployed to these devices use that or carry their own?
But then I read on, and PKI and HTTPS comes up. Is centrally managed then referring to PKI being a centralized trust system, and so is the question really "are you using CA issued domain certs"? Why the contrived phrasing then?
And then there's a mention of an internal domain name. Internal as in private? Sounds a bit suspect that the guys who don't know what a certificate is would have a private DNS with a private CA to boot, but it sure would be centralized alright.
I think it's inquisitive that the first common point reached was HTTPS: yes/no? -> yes. But then even that was seemingly a bit too new info: in the portrayed discussion it is first also asked whether HTTP is in picture. This makes me question, just what did the author even know about these devices when they prompted their centrally managed certificates question.
Maybe a better question at that stage would have been, "So, how do these devices communicate, and what to?", letting them explain it in their own terms first?
The difference here is that you know enough to ask the follow-up questions
In a normal OS under normal conditions, the certificate store is centrally managed by the OS vendor. The answer then is “yes”.
But it's possible to install a certificate of your own in which case the answer is probably “no” because when it expires you're going to have to to every one of those machines and install the replacement.
Or imagine an embedded computer that doesn't even have an OS. Then the certificate store just has whatever the developer put into it when they built the image. Again the answer is “no”. If you're lucky you can still rebuild the image and reflash the devices even though the engineer who did the work was fired as a cost–cutting measure. If you're not lucky then that VP’s cost–cutting has actually added a lot of cost.
> For Security Professionals (us): Stop being gatekeepers and start being enablers. Put down the "How do you not know this?" attitude and pick up the "Let me explain why this matters" approach.
Eeeehhhh… gatekeeping is, IMO, not quite the right term.
On the one hand, gatekeeping is restricting access until conditions are met, regardless of how spurious and irrational those conditions are. And usually, despite some pretty insane conditions. Questioning the fundamental competency of someone who ought to know even just a little better is challenging why they aren’t already possessing access, not preventing access in the first place.
On the other hand, most people in the IT industry love to talk about all the little shinies they are obsessed about. So while they may not be the best teachers in the first place, tickle their passionate shinies hard enough and they will talk your ear clean off, down the hallway, drop it through the lift and have it staggering bloody and beaten onto the sidewalk outside before you can get a word in edgewise. So getting people in IT to be advocates for the work subjects they are passionate about is not the problem - it’s training them how to deliver that information effectively to someone not in the know and not initially passionate about it.
On the gripping hand, there are plenty of people in almost every industry for whom ”How do you NOT know about this core component of your job??” is a very valid criticism to lob with great enthusiasm at them. A verbal shock like this can be very useful for disturbing a person out of their complacency, especially if they already see themselves as an SME. The real trick is following that statement up with something that can truly inspire and encourage them to willingly reach for competency in that component.
Unfortunately a lot of documentation and tooling for TLS apis are horrible.
For example when working with Apple's Network.Framework, I have to drop to C and use functions like "sec_protocol_options_add_tls_application_protocol". Maybe the new beta framework is better.
Or if I want to get a certificate hash on the command line in a usable format, I'd have to run "openssl x509 -in server.crt -noout -fingerprint -sha256 | sed 's/://g' | cut -d= -f2"
Networking and security is still a dark art and it shouldn't be.
Great read! The analogy between physics and infosec is spot-on—both rely on understanding fundamental principles that are often overlooked. The "AES256-over-HTTP" anecdote is both hilarious and terrifying, highlighting how abstraction can hide critical gaps. As a dev, I see similar issues when devs prioritize speed over security basics. Curious—what’s your go-to approach for teaching devs about PKI or mTLS without overwhelming them?
>Now, I'm not blaming developers. Modern software engineering is built on abstraction layers, and that's actually amazing! We've gone from assembly language to high-level frameworks, from bare metal to cloud-native platforms. A developer can slap a @RestController annotation on a Java class and magically have an HTTPS endpoint without knowing anything about TLS handshakes or certificate chains.
Well, you should blame the developer if they don't know the basics of computer science (TLS handshake being the basics)
I agree that programmers should know it, but I don't think Diffie-Hellman key exchange is core computer science.
It’s definitely possible to properly implement TLS without fully understanding the exact mechanics
I am gonna be that guy but;
Is a bad thing. Most people only skims the surface of what they use in daily life. Obviously there are so many things that it is hard to do otherwise. But this job is one time only...Which is why AI seemingly replacing junior engineers, because AI does the same thing, faster and cheaper...
Meanwhile, I as an engineer, see less and less appreciation and importance in my organization about "knowing" these stuff.
very good philosphy, near the end author says "Think of yourself as a physics teacher, not a physics textbook." Very good. As for appearing surprised that many people do not care, so it is.
Everyone has a relative that after 30 years still doesn't know how to use the airco controls?
I read somewhere it all follows some sort of gaussian/normal distribution, like in 11 peole there might be 1 knowledgeable, 2 interested, 5 pretending to listen, 2 bored, 1 sneaking out. Sometimes it's you or me who sneaks out.
The relationship between physics, functional programming and security feels forced.
Like I can see functional programming and physics but security just feels arbitrary.
the underlying connection the author is making between physics and security is knowing the low level laws governing the systems you are dealing with, or at least being aware of them. if anything the functional programming bit could have been left out.
The low level laws "governing" security are just procedural rules made up by humans. There could be a thousand ways to "secure" something but the author is just following convention here.
The axioms of functional programming and physics are not arbitrary conventions. They are fundamental to reality.
At its foundation modern security is based on ideas from information theory and cryptography that were discovered, not invented. Arguably just as fundamental as the postulates of general relativity or quantum mechanics.
Doesn't change a thing. All things are derived from fundamental principles.
IT Security is an arbitrary methodology derived from fundamental principles, but it doesn't change the fact that it's arbitrary.
I can make up dozens of ways to make something "secure" that doesn't follow convention. Why isn't he using biometric data like saliva DNA testing to verify identity? And why are they using a channel that anyone can peek at? Send the signals and credentials over a blinking laser light and therefore we know if the laser is disrupted we have someone trying to peek at the encrypted signal.
See what I'm saying, I can arbitrarily come up with dozens of ways to make things not only just as secure, but MORE secure. IT security is mostly memorization of convention. These conventions are derived from fundamentals, they are not principles themselves. There are thousands of orthogonal methodologies to achieve the same level of secureness but the set we use for IT are just an arbitrary selection out of an infinite amount of possibilities.
but that's not the analogy the article was making at all! it was making an analogy with using technology based on underlying physical principles, where you could either be cognizant or ignorant of those principles, and similarly you could use something like https while either knowing or not knowing what the lower level pieces it relied on were.
Yeah and I'm saying it's a bad analogy. Because the principles of security are made up. They aren't fundamental. They are arbitrary and they exist by convention.
Usually concepts that are arbitrary I wouldn't call "principles" because they aren't principles. Just convenient rules to follow. A principle is much deeper.
I think that technical people tend to see their area of expertise the most fundamental one, from which everything else derives.
This guy specialized in security and so he thinks that the concepts that he learned underlying everything, and everything else is just application.
But he's making the same mistake as everyone else. Everybody has gaps in their knowledge, it's just that he chooses to talk down to people who have their in their knowledge in _his_ area of expertise. Physicists do this a lot (I should know: I trained as a physicist so I know a lot of physicists). "Physics is really everything, everything else could be deducted from physics in principle, so no point spending time thinking about it". He carried this attitude into the next area of expertise he learned.
I'm with the project manager. "How does the gorb fleem the leemaflop?" Don't know, don't care, you do your job and I do mine. Time is finite and I'd rather spend my time on things I find intellectually stimulating, not IT security. The irony is, if everybody could reliably answer those questions, he wouldn't have a job. I find the lack of understanding quite disgusting frankly.
Yeah, he is talking a bit down to everybody.