That being said, my "ideal" solution to architecture problems in general isn't to fix architecture problems, its to have a physically separate introspection processor. One which is cheap, simple, open source, and replacable, which runs a watchdog firmware that monitors the CPU.
-
-
Replying to @hedgeberg @JaceCear
It's the easiest way to fix these flaws: have a fundamentally separate SoC with a small attack surface in a purely management role, which is responsible for confirming main CPU's behavior is in line with expectations. Like ME, but external and auditable.
1 reply 0 retweets 3 likes -
Replying to @hedgeberg @JaceCear
How would this work? If it has to monitor everything the main CPU does, it has to be as powerful as the main CPU. If it doesn't, then you could make the main CPU do evil things that it wouldn't catch.
2 replies 0 retweets 4 likes -
It wouldn’t be to different from monitoring software currently used. The goal is detection of malicious activity, so if you can do classification and identification fast enough you don’t need to replicate the CPU.
2 replies 0 retweets 0 likes -
I mean, we all know antivirus doesn't work. Reactive technologies are great and all, but how would you fundamentally distinguish malicious behavior from normal operation besides known signatures?
2 replies 0 retweets 1 like -
I am similarly lost as to the how, but I’m given the impression that it is already employed in some high security environments. I was once told in avionics systems the working assumption is an attacker is already inside, and may have rooted one of the computers onboard.
1 reply 0 retweets 0 likes -
Replying to @siriusfox @marcan42 and
The implication being multiple systems would filter each other’s data, identify strange behavior, and restart each other as required. I don’t think it’s easy or efficient, but like most attacks we gauge risk and acessabulity to the surface when we craft countermeasures.
1 reply 0 retweets 0 likes -
I think you're mixing together redundant voting systems and security. Having things like 3 identical systems doing the same thing and cross checking each other is common in avionics, but that's for reliability. If you're an attacker you just compromise all 3 at once.
2 replies 0 retweets 0 likes -
Replying to @marcan42 @siriusfox and
Ultimately you could try to have something like multiple independent implementations of the same process to safeguard against individual bugs, but that kind of approach isn't really going to fly (no pun intended) for general-purpose software.
1 reply 0 retweets 1 like -
I completely agree. I suspect that limited introspection can identify a reasonable number of attacks in progress though.
1 reply 0 retweets 0 likes
We already have those kinds of defenses, though. It's the grsecurity approach: panic the system at first sign of trouble. If an attack fails you can detect it; if it succeeds you won't notice it though. But software is buggy enough that you end up with many false positives.
-
-
I wasn’t actually aware of that. Getting back to the initial thread though, pushing that style of protection down to the hardware layer is a first step that is probably within reach. It sounds like you have a goal in mind beyond that though?
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.