1 / 11

Precise Enforcement of Policies

After we have a policy, is there always a mechanism to enforce it? If so, can we devise a generic procedure for developing such mechanisms?. Precise Enforcement of Policies. set of reachable states with mechanisms. set of secure states. precise. secure.

bernard
Download Presentation

Precise Enforcement of Policies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. After we have a policy, is there always a mechanism to enforce it? If so, can we devise a generic procedure for developing such mechanisms? Precise Enforcement of Policies set of reachable states with mechanisms set of secure states precise secure

  2. A program p is modeled as a function p: I1 x I2 x...x Inr Assumption on Observability All information available about I1 x I2 x...x In are encoded in the function p(I1,I2, In) A protection mechanism: Let p: I1 x I2 x...x Inr be a function. and let m(I1,I2, In) = p(I1,I2, In) or m(I1,I2, In)eE That is, m produces the same output as p or an error. The A. Jones + R. Lipton Model

  3. Objective is to secure a program p that takes inputs I1 I2 ... In and outputs some r A protection mechanism m takes the same inputs I1 I2 ... In and outputs either the same r or some errorE A Visualization of the Model set of reachable states without mechanisms set of secure states

  4. Definition: A confidentiality policy for p: I1 x I2 x...x Inr is a function c: I1 x I2 x...x In A where A is a subset ofI1xI2x...xIn Definition: A confidentiality policy c is secure with respect to a security mechanism m iff there is a function m’: A  R U E satisfying m (i1,i2,in)= m’ (c(i1,i2,in)) Example: consider a password accepting function auth with respect to a database Db with output {good, bad} auth: U x P x Db  {good, bad}, where Db contains pairs of (u,pwd) that are allowed. The the confidentiality policy allow(i1,i2,i3)=(i1,i2). Then there is NO function auth’ satisfying auth’(allow(i1,i2,i3))= auth’(i1,i2)= auth(i1,i2,i3) The A. Jones + R. Lipton Model Cont.

  5. Mechanisms for enforcing policies are typically too-restrictive m1, m2 are distinct mechanisms for program p under same policy m1 as precise as m2 (m1 m2) if, for all inputs i1, …, in , m2(i1, …, in) = p(i1, …, in) m1(i1, …, in) = p(i1, …, in) Precision m1 m2 set of reachable states without mechanisms set of secure states

  6. Let m3 = m1m2 For inputs on which m1 and m2 outputs same value as p, m3 does also; otherwise, m3 returns same value as m1 Theorem: if m1, m2 are secure, then m3 is secure Also, m3m1 and m3m2 Combining Mechanisms m1 m2 set of reachable states without mechanisms set of secure states

  7. For any program p and security policy c, there exists a precise, secure mechanism m* such that, for all secure mechanisms m associated with p and c, m* m m* = i=1, mi Existence Theorem mi set of reachable states without mechanisms set of secure states

  8. Theorem: There is no effective procedure that determines a maximally precise, secure mechanism for any policy and program. Proof analogous to that of undecidable problem However, possible to get a maximally precise secure mechanism for specific cases. Lack of Effective Procedure

  9. Policies describe what are (not) allowed Trust underlies everything DAC and MAC (ORCON) Formal languages are required to specify policy Precise enforcement of policies is generally difficult Key Points

  10. (Source: http://www.pcmag.com/article2/0,1895,1853366,00.asp) Go back From: update@microsoft.com Subject: What You Need to Know About the Zotob.A Worm. What You Should Know About Zotob Published: August 14, 2005 | Updated: August 19, 2005 Severity VirusGreen Supported Software Affected Windows All Version Microsoft Security Advisory 899588 Zotob.A Zotob.B Zotob.C Zotob.D Zotob.E Bobax.O Esbot.A Rbot.MA Rbot.MB Rbot.MC Appendix 1: Fake Windows Patch Is a Windows Killer Zotob is a worm that targets All Windows computers and takes advantage of a security issue that was addressed by Microsoft Security Bulletin MS05-039. This worm installs malicious software, and then searches for other computers to infect. If you have installed the update released with Security Bulletin MS05-039, you are protected from Zotob and its variants. If you are using any supported version of Windows, you are not at risk. The attachment is named MS05-039.EXE. It is 21,229 bytes and is compressed with the MEW program. When the attachment is executed, it first downloads a second Trojan program, Agent.AII, and executes it. This program downloads additional malware which logs keystrokes and accesses multiple web sites. It also attempts to modify the settings of security programs on the user's computer.

  11. Ken Thompson's 1983 Turing Award lecture to the ACM admitted the existence of a back door in early Unix versions that may have qualified as the most fiendishly clever security hack of all time. In this scheme, the C compiler contained code that would recognize when the `login' command was being recompiled and insert some code recognizing a password chosen by Thompson. So the compiled Unix system has a backdoor whereas the source code is clean. More amazingly, Thompson also arranged that the compiler would recognize when it was compiling a version of itself, and insert into the recompiled compiler the hack codes required to get him the password, and also to recognize itself and do the whole thing again the next time around! Consequently, when someone suspected the compiler and attempted to recompile the compiler from a clean source, he had to use the hacked compiler to recompile the compiler – which would of course be a hacked version again! The hack perpetuated itself invisibly, leaving the back door in place and active but with no trace in the sources. (See full story at http://www.acm.org/classics/sep95/) Appendix 2: True Story about a Back Door

More Related