If we looked at the machine systems and how they essay to provide security, I conceive we could categorize those attempts into three broad categories:
1) Security by Correctness
2) Security by Isolation
3) Security by Obscurity
Let's discuss those categories in more discourse below.
Security by Correctness
The assumption here is obvious: if we crapper produce cipher that doesn't hit bugs (nor whatever maliciously behaving code), then we don't hit section problems at all. The exclusive difficulty is that we don't hit whatever tools to attain trusty that a presented cipher is correct (in terms of implementation, design and right behavior). But if we look at various efforts in machine science, we module attending a lot of effort has been prefabricated to attain Security by Correctness: \"safe\" languages, cipher verifiers (although not good ones, meet heuristic based), developer's education, drill cipher audit, etc. Microsoft's notable Secure Development Life-cycle is every most Security by Correctness. The exclusive difficulty is: every those approaches sometimes impact and sometimes do not, sometimes they miss whatever fault and also there are problems that I simple don't believe crapper be addresses by semiautomatic cipher verifiers or modify innocuous languages, like e.g. logic/design bugs or determining on wheatear a presented cipher behaves maliciously or not (after every this is an right difficulty in whatever cases, not a machine science problem).
To sum it: I conceive that in whatever more or less distant forthcoming (some grouping conceive abuout a timeframe of 50 eld or so), we would intend rid of every the implementation bugs, thanks to innocuous languages and/or good cipher verifiers. But I don't believe we could assure correctness of cipher on whatever higher level of abstraction then implementation level.
Security by Isolation
Because of the problems with effectively implementing Security by Correctness approach, people, from the rattling beginning, has also taken added approach, which is supported on isolation. The idea is to split a machine grouping into smaller pieces and attain trusty that apiece warning is distributed from the another ones, so that if it gets compromised/malfunctions, then it cannot change the another entities in the system. Early UNIX's user accounts and removed impact come spaces, things that are now present in every modern OS, are examples of Security by Isolation.
Simple as it sound, in practice the separation move overturned discover to be rattling tricky to implement. One difficulty is how to partition the grouping into meaning pieces and how to set permissions for apiece piece. The another difficulty is implementation - e.g. if we verify a contemporary consumer OS, like Vista, UNIX or Mac OSX, every of them hit monolithic kernels, meaning that a simple fault in whatever of the essence components (think: hundreds of 3rd band drivers streaming there), allows to bypass of the separation mechanisms provided by the essence to the rest of the grouping (process separation, ACLs, etc).
Obviously the difficulty is because the kernels are monolithic. Why not compel Security by Isolation on a essence level then? Well, I would personally love that approach, but the industry simply took added course and decided that monolithic kernels are better then micro-kernels, because it's easier to write the cipher for them and (arguably) they offer better performance.
Many believe, including myself, that this genre crapper be denaturized by the virtualization technology. Thin bare-metal hypervisor, like e.g. Xen, crapper act like a micro essence and enforce separation between another components in the grouping - e.g. we crapper move drivers into a removed domain and separate them from the rest of the system. But again there are challenges here on both the design- as well as the implementation-level. For example, we should not put every the drivers into the same domain, as this would provide little transformation in security. Also, how to attain trusty that the hypervisor itself is not buggy?
Security by Obscurity (or Security by Randomization)
Finally we hit the Security by Obscurity move that is supported on the assumption that we cannot intend rid of every the bugs (like in Security by Isolation approach), but at small we crapper attain exploitation of those bugs rattling hard. So, it's every most making our grouping unfriendly to the attacker.
Examples of this move allow Address Space Layout Randomization (ASLR, present in every newer OSes, like Linux, Vista, OSX), StackGuard-like protections (again utilised by most contemporary OSes), indicator encryption (Windows and Linux) and belike whatever another mechanisms that I can't remember at the moment. Probably the most extremity warning of Security by Obscurity would be to use a compiler that generates heavily obfuscated binaries from the source cipher and creates a unique (on a binary level) instances of the same system. Alex did his PhD on this matter and his an expert on compilers and obfuscators.
The obvious disadvantage of this move is that it doesn't preclude the bugs from being exploited - it exclusive attain the meaning exploitation rattling hard or modify impossible. But if digit is concerned also most e.g. DoS attacks, then Security by Obscurity module not preclude them in most cases. The another difficulty with obfuscating the cipher is the performance (compiler cannot optimize the cipher for speed) and fix (if we got a crash dump on an \"obfuscated\" Windows box, we couldn't count on hold from the theoretical support). Finally there is a difficulty of proving that the whole scheme is correct and that our obfuscator (or e.g. ASLR engine) doesn't introduce bugs to the generated cipher and that we module not intend random crashes after (that we would be most probable unable to debug, as the cipher module be obfuscated).
I wonder if the above arrangement is complete and if I haven't forgotten most something. If you know an warning of a section move that doesn't fit here (besides blacklisiting), please let me know!
1) Security by Correctness
2) Security by Isolation
3) Security by Obscurity
Let's discuss those categories in more discourse below.
Security by Correctness
The assumption here is obvious: if we crapper produce cipher that doesn't hit bugs (nor whatever maliciously behaving code), then we don't hit section problems at all. The exclusive difficulty is that we don't hit whatever tools to attain trusty that a presented cipher is correct (in terms of implementation, design and right behavior). But if we look at various efforts in machine science, we module attending a lot of effort has been prefabricated to attain Security by Correctness: \"safe\" languages, cipher verifiers (although not good ones, meet heuristic based), developer's education, drill cipher audit, etc. Microsoft's notable Secure Development Life-cycle is every most Security by Correctness. The exclusive difficulty is: every those approaches sometimes impact and sometimes do not, sometimes they miss whatever fault and also there are problems that I simple don't believe crapper be addresses by semiautomatic cipher verifiers or modify innocuous languages, like e.g. logic/design bugs or determining on wheatear a presented cipher behaves maliciously or not (after every this is an right difficulty in whatever cases, not a machine science problem).
To sum it: I conceive that in whatever more or less distant forthcoming (some grouping conceive abuout a timeframe of 50 eld or so), we would intend rid of every the implementation bugs, thanks to innocuous languages and/or good cipher verifiers. But I don't believe we could assure correctness of cipher on whatever higher level of abstraction then implementation level.
Security by Isolation
Because of the problems with effectively implementing Security by Correctness approach, people, from the rattling beginning, has also taken added approach, which is supported on isolation. The idea is to split a machine grouping into smaller pieces and attain trusty that apiece warning is distributed from the another ones, so that if it gets compromised/malfunctions, then it cannot change the another entities in the system. Early UNIX's user accounts and removed impact come spaces, things that are now present in every modern OS, are examples of Security by Isolation.
Simple as it sound, in practice the separation move overturned discover to be rattling tricky to implement. One difficulty is how to partition the grouping into meaning pieces and how to set permissions for apiece piece. The another difficulty is implementation - e.g. if we verify a contemporary consumer OS, like Vista, UNIX or Mac OSX, every of them hit monolithic kernels, meaning that a simple fault in whatever of the essence components (think: hundreds of 3rd band drivers streaming there), allows to bypass of the separation mechanisms provided by the essence to the rest of the grouping (process separation, ACLs, etc).
Obviously the difficulty is because the kernels are monolithic. Why not compel Security by Isolation on a essence level then? Well, I would personally love that approach, but the industry simply took added course and decided that monolithic kernels are better then micro-kernels, because it's easier to write the cipher for them and (arguably) they offer better performance.
Many believe, including myself, that this genre crapper be denaturized by the virtualization technology. Thin bare-metal hypervisor, like e.g. Xen, crapper act like a micro essence and enforce separation between another components in the grouping - e.g. we crapper move drivers into a removed domain and separate them from the rest of the system. But again there are challenges here on both the design- as well as the implementation-level. For example, we should not put every the drivers into the same domain, as this would provide little transformation in security. Also, how to attain trusty that the hypervisor itself is not buggy?
Security by Obscurity (or Security by Randomization)
Finally we hit the Security by Obscurity move that is supported on the assumption that we cannot intend rid of every the bugs (like in Security by Isolation approach), but at small we crapper attain exploitation of those bugs rattling hard. So, it's every most making our grouping unfriendly to the attacker.
Examples of this move allow Address Space Layout Randomization (ASLR, present in every newer OSes, like Linux, Vista, OSX), StackGuard-like protections (again utilised by most contemporary OSes), indicator encryption (Windows and Linux) and belike whatever another mechanisms that I can't remember at the moment. Probably the most extremity warning of Security by Obscurity would be to use a compiler that generates heavily obfuscated binaries from the source cipher and creates a unique (on a binary level) instances of the same system. Alex did his PhD on this matter and his an expert on compilers and obfuscators.
The obvious disadvantage of this move is that it doesn't preclude the bugs from being exploited - it exclusive attain the meaning exploitation rattling hard or modify impossible. But if digit is concerned also most e.g. DoS attacks, then Security by Obscurity module not preclude them in most cases. The another difficulty with obfuscating the cipher is the performance (compiler cannot optimize the cipher for speed) and fix (if we got a crash dump on an \"obfuscated\" Windows box, we couldn't count on hold from the theoretical support). Finally there is a difficulty of proving that the whole scheme is correct and that our obfuscator (or e.g. ASLR engine) doesn't introduce bugs to the generated cipher and that we module not intend random crashes after (that we would be most probable unable to debug, as the cipher module be obfuscated).
I wonder if the above arrangement is complete and if I haven't forgotten most something. If you know an warning of a section move that doesn't fit here (besides blacklisiting), please let me know!
0 comments:
Post a Comment