- CEO gets a Letter. Does the CEO start learning Python/C++/PHP and Cisco configuration? Or does he tell a worker bee "Shhh! And read this Letter" ?
- Worker bee starts making changes to production code and systems. Suddenly he starts needing automated code reviews, and reconfiguration alerts go out when he frobs the firewalls. These changes are indistinguishable from an infiltrator with the worker-bee's credentials and ideally things are set up so that changes are generally shared around, a normal review process, to catch out-of-control worker bees.
- The build lab scripts are modified (by who?) to insert bad code. Oh, but the build checkers catch this ("Hey, we found a compiler bug!" / "Umm, no you didn't..."). Everybody starts handing around links to "Reflections on Trusting Trust".
- Things get even more exciting when the internal monitoring systems discover (say) equipment attached to the network that ain't supposed to be there. "Wot's all this then," says the network engineer, and he yanks the cables to the SkankSec-1000 that someone hot-wired into a rack. "Oh yeah, blue fiber is for NSA, green is for CIA, yellow is for GCHG, and black is for Russians, what else?" He leaves it unplugged. Let's ignore the security camera footage in the datacenter, since this is a thought experiment.
In an environment with self-monitoring for health and intrusion detection, applying changes for user surveillance requires quite a lot of internal cooperation and communication. No wonder the Yahoo stuff looked like a Bad Guy who got in.
We can probably extend the internal defenses to alerting on odd access patterns to sensitive database rows, too . . .
The easiest way is probably to create a bullshit project with a few people. We are only creating a new dashboard for X, this is cost reduction project, etc.
I don't know how Yahoo is organized but if teams works in silos, without any visibility on other teams, it is probably not that hard to introduced changes that are undetected.
In a place where everything is monitored, down to the MAC address of machines and their network traffic, ideally it would be difficult to sneak in a monitor.
Access to critical data should be similarly protected.
These are relatively tame intrusion detection systems that you would have to make changes to in order to remain undetected. That should be really hard to hide.
- CEO gets a Letter. Does the CEO start learning Python/C++/PHP and Cisco configuration? Or does he tell a worker bee "Shhh! And read this Letter" ?
- Worker bee starts making changes to production code and systems. Suddenly he starts needing automated code reviews, and reconfiguration alerts go out when he frobs the firewalls. These changes are indistinguishable from an infiltrator with the worker-bee's credentials and ideally things are set up so that changes are generally shared around, a normal review process, to catch out-of-control worker bees.
- The build lab scripts are modified (by who?) to insert bad code. Oh, but the build checkers catch this ("Hey, we found a compiler bug!" / "Umm, no you didn't..."). Everybody starts handing around links to "Reflections on Trusting Trust".
- Things get even more exciting when the internal monitoring systems discover (say) equipment attached to the network that ain't supposed to be there. "Wot's all this then," says the network engineer, and he yanks the cables to the SkankSec-1000 that someone hot-wired into a rack. "Oh yeah, blue fiber is for NSA, green is for CIA, yellow is for GCHG, and black is for Russians, what else?" He leaves it unplugged. Let's ignore the security camera footage in the datacenter, since this is a thought experiment.
In an environment with self-monitoring for health and intrusion detection, applying changes for user surveillance requires quite a lot of internal cooperation and communication. No wonder the Yahoo stuff looked like a Bad Guy who got in.
We can probably extend the internal defenses to alerting on odd access patterns to sensitive database rows, too . . .