3 ms·

And we're surprised? Didn't we learn anything from the 90's? No amount of diligence sitting at a desk, carefully evaluating the implications of the placement/th

And we're surprised? Didn't we learn anything from the 90's? No amount of diligence sitting at a desk, carefully evaluating the implications of the placement/thoroughness of your user input sanitation, adjusting the settings in server configuration files, preventing your employees from using removable media and accessing outside sites... No threat model, seriously none.. ever.. will ever.. Stop a young Angelina Jolie on rollerblades from gaining access to your evil corporations's super computer and thwarting your carefully laid, super-villain plan.

unit91 9y ago
There's so much sarcasm in your post that I'm not sure I understand your point. Can you clarify?
- blanket_the_cat 9y ago
  Let me rephrase that; Skipping reindexing punch cards: If your adversary can write some ASM to get the EIP to point to a malicious instruction, they can instruct your system to do something you don't necessarily want it to do. Then our homies at bell labs built C, as a layer of abstraction to ASM. With C, your adversary has several ways to accomplish getting the EIP to his malicious instruction. Then, over the years, many brilliant, incredible minds, (no sarcasm about that. None.) have built abstractions to simplify C, and then built abstractions on top of those abstractions, and then abstractions to simplify those abstractions. (I'm totally not even going to touch networking protocols) There is decades, of building systems with flaws, on top of systems with security flaws, (which admittedly wasn't as much of a concern to anyone, as providing the functionality to accomplish objectives, business and otherwise) ... literally, like over half a century of this. So then these middle-management suits, operating with "LEAN 6-Sigma" misconceptions about the nature of the world, expect a kid, with a degree in anthropology (not knocking the study) to run through a 12-week intensive program, and be able to write code for a production system, with perhaps 2 people on their dev team of 8-16, and 3 folks in devops/IT who understand security to be able to proof all of that code, and make sure that your Gibson is bulletproof? It's unrealistic. If she wants to hack your Gibson, she's going to hack your Gibson. We're all going to attempt to stop that, and after we've failed, we will spend days filling out reports, talking to feds, and mitigating the damage. But we're continuously building onto a flawed mechanism, with another flawed mechanism. I mean, do you know any civil engineers who would say, "Oh hey this foundation is cracked, let's build something that tries to patch those cracks, and when that's broken, we'll build another level on top of that, and let's just obfuscate what's really going on underneath everything so that nobody who uses the building realizes it's unstable, and just hope it doesn't get too windy, or that there is an earthquake." ? Ipso Facto: When you launch some ransomware, that threatens the software reading a gyroscope to tip over an oil tanker if you aren't paid $1,000,000, and try to blame it on some kids who's only crime was curiosity, they will find a way to subvert the carefully measured security mechanisms you have put in place, to not only clear their names, and prove beyond the shadow of doubt that it was in fact YOU, who hatched this terrible plot, but also save the environment. Sorry, I should have said that to begin with.
  - NeutronBoy 9y ago
    > I mean, do you know any civil engineers who would say, "Oh hey this foundation is cracked, let's build something that tries to patch those cracks, and when that's broken, we'll build another level on top of that, and let's just obfuscate what's really going on underneath everything so that nobody who uses the building realizes it's unstable, and just hope it doesn't get too windy, or that there is an earthquake." No, but civil engineers say stuff like "What's the likelihood that a 9.5 earthquake will his this area? What about a 5?" and model their designs on that. That's the point behind threat modelling - if a nation state actor decides they want to 'hack your Gibson' that's one thing, but if you're a bank than it may be that your most likely threat is employees or contractors stealing customer data. So you put your effort into protecting against those threats as well.

unit91 9y ago

There's so much sarcasm in your post that I'm not sure I understand your point. Can you clarify?

blanket_the_cat 9y ago
Let me rephrase that; Skipping reindexing punch cards: If your adversary can write some ASM to get the EIP to point to a malicious instruction, they can instruct your system to do something you don't necessarily want it to do. Then our homies at bell labs built C, as a layer of abstraction to ASM. With C, your adversary has several ways to accomplish getting the EIP to his malicious instruction. Then, over the years, many brilliant, incredible minds, (no sarcasm about that. None.) have built abstractions to simplify C, and then built abstractions on top of those abstractions, and then abstractions to simplify those abstractions. (I'm totally not even going to touch networking protocols) There is decades, of building systems with flaws, on top of systems with security flaws, (which admittedly wasn't as much of a concern to anyone, as providing the functionality to accomplish objectives, business and otherwise) ... literally, like over half a century of this. So then these middle-management suits, operating with "LEAN 6-Sigma" misconceptions about the nature of the world, expect a kid, with a degree in anthropology (not knocking the study) to run through a 12-week intensive program, and be able to write code for a production system, with perhaps 2 people on their dev team of 8-16, and 3 folks in devops/IT who understand security to be able to proof all of that code, and make sure that your Gibson is bulletproof? It's unrealistic. If she wants to hack your Gibson, she's going to hack your Gibson. We're all going to attempt to stop that, and after we've failed, we will spend days filling out reports, talking to feds, and mitigating the damage. But we're continuously building onto a flawed mechanism, with another flawed mechanism. I mean, do you know any civil engineers who would say, "Oh hey this foundation is cracked, let's build something that tries to patch those cracks, and when that's broken, we'll build another level on top of that, and let's just obfuscate what's really going on underneath everything so that nobody who uses the building realizes it's unstable, and just hope it doesn't get too windy, or that there is an earthquake." ? Ipso Facto: When you launch some ransomware, that threatens the software reading a gyroscope to tip over an oil tanker if you aren't paid $1,000,000, and try to blame it on some kids who's only crime was curiosity, they will find a way to subvert the carefully measured security mechanisms you have put in place, to not only clear their names, and prove beyond the shadow of doubt that it was in fact YOU, who hatched this terrible plot, but also save the environment. Sorry, I should have said that to begin with.
- NeutronBoy 9y ago
  > I mean, do you know any civil engineers who would say, "Oh hey this foundation is cracked, let's build something that tries to patch those cracks, and when that's broken, we'll build another level on top of that, and let's just obfuscate what's really going on underneath everything so that nobody who uses the building realizes it's unstable, and just hope it doesn't get too windy, or that there is an earthquake." No, but civil engineers say stuff like "What's the likelihood that a 9.5 earthquake will his this area? What about a 5?" and model their designs on that. That's the point behind threat modelling - if a nation state actor decides they want to 'hack your Gibson' that's one thing, but if you're a bank than it may be that your most likely threat is employees or contractors stealing customer data. So you put your effort into protecting against those threats as well.