The attitude described here makes sense for embedded, non-networked systems. It’s certainly fun to work on systems like that.
But the idea that because you don’t have valuable data, nobody is going to attack you is naive. The people making enormous bot networks don’t care what data you have. Network connectivity itself means you have something useful for malware.
And even before that, we had viruses spread by floppy disk. Viruses don’t care whether you have valuable data either.
To pile on, just the fact your device has a CPU and GPU is valuable since it can be made a cryptocurrency mining zombie. Even if your data doesn't have external value it likely has some internal value so an attacker can encrypt it and extort you for the key.
Botnets and malware users are looking for resources. It doesn't really matter what those are exactly because they tend to use every part of the buffalo.
It seems to me that this point is addressed by the author:
Our threat is really from folks doing large-scale automated sweeps for low-hanging fruit
> The attitude described here makes sense for embedded, non-networked systems. It’s certainly fun to work on systems like that.
Well, more and more you are required to put encryption everywhere even when you are not connected to the network. Some certifications require that your device is protected against physical tinkering, even though it is inside a metal box behind a locked door in an access-restricted area.
Sometimes it feels like the "defense in depth" concept is not understood at all, because the requirements are written like if each line should be unbreakable no matter what.
I think that computer security is a noxious domain because it is so easy to FUD people; it is a domain where risk aversion has a field day any day.
First off, typically this requirements have a degree of flex in them.
Additionally, it might be your understanding of the requirements, not the requirements that are in error.
Yes, people need to encrypt their double locked box high up on a electric pole, because people will figure out how to get at it.
Unfortunately you kind of reinforced my point of view, because "double locked box high up on an electric pole" is not what I was talking about. This kind of approximation in the threat model is part of the problem, IMHO.
> Java (and C++) have a rudimentary form of access control where members can be marked private ... ostensibly in order to perform validity checks on proposed modification.
This is not the biggest reason I generally mark members as private. I tend to develop immutable classes wherever possible. I use private to indicate what is exempt from requiring API documentation.
But the idea that because you don’t have valuable data, nobody is going to attack you is naive. The people making enormous bot networks don’t care what data you have. Network connectivity itself means you have something useful for malware.
And even before that, we had viruses spread by floppy disk. Viruses don’t care whether you have valuable data either.
Botnets and malware users are looking for resources. It doesn't really matter what those are exactly because they tend to use every part of the buffalo.
Our threat is really from folks doing large-scale automated sweeps for low-hanging fruit
> The attitude described here makes sense for embedded, non-networked systems. It’s certainly fun to work on systems like that.
Well, more and more you are required to put encryption everywhere even when you are not connected to the network. Some certifications require that your device is protected against physical tinkering, even though it is inside a metal box behind a locked door in an access-restricted area.
Sometimes it feels like the "defense in depth" concept is not understood at all, because the requirements are written like if each line should be unbreakable no matter what.
I think that computer security is a noxious domain because it is so easy to FUD people; it is a domain where risk aversion has a field day any day.
Yes, people need to encrypt their double locked box high up on a electric pole, because people will figure out how to get at it.
This is not the biggest reason I generally mark members as private. I tend to develop immutable classes wherever possible. I use private to indicate what is exempt from requiring API documentation.