The problem is Philips have been burned by all the stunt hacking done on their bulbs and IOT in general. They're damned if they do and damned if they don't.
If they _do_ all the stupid security things they get this.
If they _don't_ do all the stupid security things they get sensational headlines where stunt hackers use drones to infect all the lights in an office building.
Philips had a security assessment on their app for all the obvious reasons. [I am simplifying, it may be part of their standard development process at this point to add these things].
That assessment came back with (among others) the findings:
xyz.124: No app obfuscation: our testers were able to reverse engineer the app and...
xyz.125: No jailbreak detection. During the assessment...
I've seen apps that _really_ don't need these things come back with these findings in reports from supposedly big, reputable security firms. That is partly because the findings are _right there_ in the methodology and pre-written, and it's low effort for the tester to paste them in and pad out their report. There is also the argument that its better to tell the customer they don't have those things and let them decide whether to accept the risk.
If you don't have engineers who can push back on "not applicable" security findings (or you have a team priority to reduce risk at any cost) then this is what happens.
It is also remotely possible that the app "needs" these things because the firmware is unsigned and they are concerned about stunt hackers posting on twitter about the funny or mildly nefarious things they can do with the brushes.
Jailbreak detection is not an exact science so you will inevitably get outcomes like this.
I get your point about preventing low level hacks, but isn't
If they _don't_ do all the stupid security things they get sensational headlines where stunt hackers use drones to infect all the lights in an office building
Kind of beside the point? If you do the right security things you can ensure only the right person gets acceses, i.e. the owner of the device.
SDLCs in huge corporates tend to produce slightly crazy outcomes.
There are 3 reasons I know of to implement jailbreak detection. Two "real" ones and one process related.
The first is that you have implemented security controls "on the client" somewhere. In which case you need to take some control away from the user to avoid circumvention.
The second is that you cannot really tell the difference between compromise and jailbreak; that is, you are less confident that actions on the device reflect the true intent of the owner. This is why, for example, banking apps can be touchy about jailbreaks.
The third is what I believe is happening here: You got burned at some point for the other 2 reasons, it's now part of your corporate IOT security standard to add it to every app.
Sadly the cognitive cost of deciding the "perfect" set of security controls for your toothbrush app is higher (and riskier project-wise) than just following the corporate standard. So team implements feature.
Comments
The problem is Philips have been burned by all the stunt hacking done on their bulbs and IOT in general. They're damned if they do and damned if they don't.
If they _do_ all the stupid security things they get this.
If they _don't_ do all the stupid security things they get sensational headlines where stunt hackers use drones to infect all the lights in an office building.
Philips had a security assessment on their app for all the obvious reasons. [I am simplifying, it may be part of their standard development process at this point to add these things].
That assessment came back with (among others) the findings:
xyz.124: No app obfuscation: our testers were able to reverse engineer the app and...
xyz.125: No jailbreak detection. During the assessment...
I've seen apps that _really_ don't need these things come back with these findings in reports from supposedly big, reputable security firms. That is partly because the findings are _right there_ in the methodology and pre-written, and it's low effort for the tester to paste them in and pad out their report. There is also the argument that its better to tell the customer they don't have those things and let them decide whether to accept the risk.
If you don't have engineers who can push back on "not applicable" security findings (or you have a team priority to reduce risk at any cost) then this is what happens.
It is also remotely possible that the app "needs" these things because the firmware is unsigned and they are concerned about stunt hackers posting on twitter about the funny or mildly nefarious things they can do with the brushes.
Jailbreak detection is not an exact science so you will inevitably get outcomes like this.
I get your point about preventing low level hacks, but isn't
Kind of beside the point? If you do the right security things you can ensure only the right person gets acceses, i.e. the owner of the device.
SDLCs in huge corporates tend to produce slightly crazy outcomes.
There are 3 reasons I know of to implement jailbreak detection. Two "real" ones and one process related.
The first is that you have implemented security controls "on the client" somewhere. In which case you need to take some control away from the user to avoid circumvention.
The second is that you cannot really tell the difference between compromise and jailbreak; that is, you are less confident that actions on the device reflect the true intent of the owner. This is why, for example, banking apps can be touchy about jailbreaks.
The third is what I believe is happening here: You got burned at some point for the other 2 reasons, it's now part of your corporate IOT security standard to add it to every app.
Sadly the cognitive cost of deciding the "perfect" set of security controls for your toothbrush app is higher (and riskier project-wise) than just following the corporate standard. So team implements feature.