|
|
|
|
|
|
by blackflame7000
2914 days ago
|
|
|
In order to design a really secure system, wouldn't you first have to know what "secure" is? If I am an expert an building impenetrable servers, then I must know how to penetrate servers since I've added patches to block all known attacks. How could I do that without first being a hacker? See, its a progression not a dichotomy. A hacker possesses only a subset of a truly skilled security programmer. And the security programmer always has home field advantage. As a hacker becomes more seasoned, they learn more and more about the system until they reach the level of the security programmer or the person implementing all the locks and keys |
|
|
Indeed. For this one loves to build mathematical models, formulate security properties, make proofs, think deeply about the limits of the formulated models (e.g. tempest attacks, cache timings etc. which might introduce side channels) etc.
Finding exploits is quite a different job: Here you very often have lots of legacy systems which have an architecture that is hard to make secure. To give an example: A parser for a very complicated and ill-specified file format where mistakes can easily lead to catastrophes (for example because the format allows to embed "executable scripts" that are run in a JIT-based virtual machine). So you look for loopholes in an often badly designed or at least complex and thus error-prone system and think about how you can exploit these mistakes in a clever way.
I am very sure that both can be very exciting jobs, but they are in my opinion quite different in nature.
> If I am an expert an building impenetrable servers, then I must know how to penetrate servers since I've added patches to block all known attacks. How could I do that without first being a hacker?
I think the essential difference is that if you are an expert in building impenetrable servers, you simply avoid lots of design decisions that are prone to security problems (to stay in my explanation above: these also typically have the property that they can be specified rather well formally). On the other hand, if you want to penetrate servers, you need creativity to turn "suspicious looking design decisions/oversights" into working exploits.
So being an expert in building impenetrable servers will not make you good in penetrating servers: Knowing what design decisions are hard to keep in control security-wise does not (necessarily) give you the knowledge about how to concretely exploit them. On the other hand: Having a strong creativity for how one can in practice exploit oversights does not (necessarily) make you a good engineer for systems that are hard to exploit.