1 / 42

Sicurezza Informatica

Sicurezza Informatica. Prof. Stefano Bistarelli bista@dipmat.unipg.it http://www.sci.unich.it/ ~bista /. Chapter 4: security policies. Security Policy. Policy partitions system states into: Authorized (secure) These are states the system can enter Unauthorized (nonsecure)

sara-glenn
Download Presentation

Sicurezza Informatica

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. Sicurezza Informatica Prof. Stefano Bistarelli bista@dipmat.unipg.it http://www.sci.unich.it/~bista/

  2. Chapter 4: security policies Prof. Stefano Bistarelli - Sicurezza Informatica

  3. Security Policy • Policy partitions system states into: • Authorized (secure) • These are states the system can enter • Unauthorized (nonsecure) • If the system enters any of these states, it’s a security violation • Secure system • Starts in authorized state • Never enters unauthorized state Prof. Stefano Bistarelli - Sicurezza Informatica

  4. Secure System - Example Unauthorized states A B C D Authorized states • Is this Finite State Machine Secure? • A is start state ? • B is start state ? • C is start state ? • How can this be made secure if not? • Suppose A, B, and C are authorized states ? Prof. Stefano Bistarelli - Sicurezza Informatica

  5. Additional Definitions: • Security breach: system enters an unauthorized state • Let X be a set of entities, I be information. • I has confidentiality with respect to X if no member of X can obtain information on I • N.B. policy have to take in account temporal information (ex: NDA have time limit) • I has integrity with respect to X if all members of X trust I • Trust I, its conveyance and storage (data integrity) • I maybe origin information or an identity (authentication) • I is a resource – its integrity implies it functions as it should (assurance) • I has availability with respect to X if all members of X can access I • Time limits (quality of service) Prof. Stefano Bistarelli - Sicurezza Informatica

  6. Confidentiality Policy • Also known as information flow • Transfer of rights • Transfer of information without transfer of rights • Temporal context • Model often depends on trust • Parts of system where information could flow • Trusted entity must participate to enable flow • Highly developed in Military/Government Prof. Stefano Bistarelli - Sicurezza Informatica

  7. Integrity Policy • Defines how information can be altered • Entities allowed to alter data • Conditions under which data can be altered • Limits to change of data • Examples: • Purchase over $1000 requires signature • Check over $10,000 must be approved by one person and cashed by another • Separation of duties : for preventing fraud • Highly developed in commercial world Prof. Stefano Bistarelli - Sicurezza Informatica

  8. Commercial policies: Integrity and Transactions • Begin in consistent state • “Consistent” defined by specification • Perform series of actions (transaction) • Actions cannot be interrupted • If actions complete, system in consistent state • If actions do not complete, system reverts to beginning (consistent) state Prof. Stefano Bistarelli - Sicurezza Informatica

  9. Availability • X set of entities, I resource • I has availability property with respect to X if all xX can access I • Types of availability: • traditional: x gets access or not • quality of service: promised a level of access (for example, a specific level of bandwidth) and not meet it, even though some access is achieved Prof. Stefano Bistarelli - Sicurezza Informatica

  10. Policy Models • Abstract description of a policy or class of policies • Focus on points of interest in policies • Security levels in multilevel security models • Separation of duty in Clark-Wilson model • Conflict of interest in Chinese Wall model Prof. Stefano Bistarelli - Sicurezza Informatica

  11. Mechanisms • Entity or procedure that enforces some part of the security policy • Access controls (like bits to prevent someone from reading a homework file) • Disallowing people from bringing CDs and floppy disks into a computer facility to control what is placed on systems Prof. Stefano Bistarelli - Sicurezza Informatica

  12. Key Points • Policies describe what is allowed • Mechanisms control how policies are enforced • Trust underlies everything Prof. Stefano Bistarelli - Sicurezza Informatica

  13. Trust??? • Esempio segue! Prof. Stefano Bistarelli - Sicurezza Informatica

  14. Question: • Istallare una patch incrementa la security? Prof. Stefano Bistarelli - Sicurezza Informatica

  15. Dipende: Trust Administrator installs patch • Trusts patch came from vendor, not tampered with in transit • Trusts vendor tested patch thoroughly • Trusts vendor’s test environment corresponds to local environment • Trusts patch is installed correctly Prof. Stefano Bistarelli - Sicurezza Informatica

  16. Again: • Formal verification of a system! • Then we are secure?? Prof. Stefano Bistarelli - Sicurezza Informatica

  17. Trust in Formal Verification • Gives formal mathematical proof that given input i, program P produces output o as specified • Suppose a security-related program S formally verified to work with operating system O • What are the assumptions? Prof. Stefano Bistarelli - Sicurezza Informatica

  18. Trust in Formal Methods • Proof has no errors • Bugs in automated theorem provers • Preconditions hold in environment in which S is to be used • S transformed into executable S whose actions follow source code • Compiler bugs, linker/loader/library problems • Hardware executes S as intended • Hardware bugs (Pentium f00f bug, for example) Prof. Stefano Bistarelli - Sicurezza Informatica

  19. esercizio Prof. Stefano Bistarelli - Sicurezza Informatica

  20. Question • Policy disallows cheating • Includes copying homework, with or without permission • CS class has students do homework on computer • Anne forgets to read-protect her homework file • Bill copies it • Who cheated? • Anne, Bill, or both? Prof. Stefano Bistarelli - Sicurezza Informatica

  21. Answer Part 1 • Bill cheated • Policy forbids copying homework assignment • Bill did it • System entered unauthorized state (Bill having a copy of Anne’s assignment) • If not explicit in computer security policy, certainly implicit • Not credible that a unit of the university allows something that the university as a whole forbids, unless the unit explicitly says so Prof. Stefano Bistarelli - Sicurezza Informatica

  22. Answer Part 2 • Anne didn’t protect her homework • Not required by security policy • She didn’t breach security • If policy said students had to read-protect homework files, then Anne did breach security • She didn’t do this Prof. Stefano Bistarelli - Sicurezza Informatica

  23. Access Control • Discretionary Access Control (DAC) • Owner determines access rights • Typically identity-based access control (IBAC): Owner specifies other users who have access • Mandatory Access Control (MAC) • Rules specify granting of access • Also called rule-based access control • Indipendente dal soggetto!! Prof. Stefano Bistarelli - Sicurezza Informatica

  24. Access Control • Originator Controlled Access Control (ORCON) • Originator controls access • Originator need not be owner! • Role Based Access Control (RBAC) • Identity governed by role user assumes Prof. Stefano Bistarelli - Sicurezza Informatica

  25. Example policy • Bishop University Prof. Stefano Bistarelli - Sicurezza Informatica

  26. Example English Policy • Computer security policy for academic institution • Institution has multiple campuses, administered from central office • Each campus has its own administration, and unique aspects and needs • Authorized Use Policy • Electronic Mail Policy Prof. Stefano Bistarelli - Sicurezza Informatica

  27. Authorized Use Policy • Intended for one campus (Davis) only • Goals of campus computing • Underlying intent • Procedural enforcement mechanisms • Warnings • Denial of computer access • Disciplinary action up to and including expulsion • Written informally, aimed at user community Prof. Stefano Bistarelli - Sicurezza Informatica

  28. Electronic Mail Policy • Systemwide, not just one campus • Three parts • Summary • Full policy • Interpretation at the campus Prof. Stefano Bistarelli - Sicurezza Informatica

  29. Summary • Warns that electronic mail not private • Can be read during normal system administration • Can be forged, altered, and forwarded • Unusual because the policy alerts users to the threats • Usually, policies say how to prevent problems, but do not define the threats Prof. Stefano Bistarelli - Sicurezza Informatica

  30. Summary • What users should and should not do • Think before you send • Be courteous, respectful of others • Don’t nterfere with others’ use of email • Personal use okay, provided overhead minimal • Who it applies to • Problem is UC is quasi-governmental, so is bound by rules that private companies may not be • Educational mission also affects application Prof. Stefano Bistarelli - Sicurezza Informatica

  31. Full Policy • Context • Does not apply to Dept. of Energy labs run by the university • Does not apply to printed copies of email • Other policies apply here • E-mail, infrastructure are university property • Principles of academic freedom, freedom of speech apply • Access without user’s permission requires approval of vice chancellor of campus or vice president of UC • If infeasible, must get permission retroactively Prof. Stefano Bistarelli - Sicurezza Informatica

  32. Uses of E-mail • Anonymity allowed • Exception: if it violates laws or other policies • Can’t interfere with others’ use of e-mail • No spam, letter bombs, e-mailed worms, etc. • Personal e-mail allowed within limits • Cannot interfere with university business • Such e-mail may be a “university record” subject to disclosure Prof. Stefano Bistarelli - Sicurezza Informatica

  33. Security of E-mail • University can read e-mail • Won’t go out of its way to do so • Allowed for legitimate business purposes • Allowed to keep e-mail robust, reliable • Archiving and retention allowed • May be able to recover e-mail from end system (backed up, for example) Prof. Stefano Bistarelli - Sicurezza Informatica

  34. Implementation • Adds campus-specific requirements and procedures • Example: “incidental personal use” not allowed if it benefits a non-university organization • Allows implementation to take into account differences between campuses, such as self-governance by Academic Senate • Procedures for inspecting, monitoring, disclosing e-mail contents • Backups Prof. Stefano Bistarelli - Sicurezza Informatica

  35. Discussion: Prof. Stefano Bistarelli - Sicurezza Informatica

  36. Esempio di politica di sicurezza • Un utente ha il permesso di leggere un qualunque file pubblico • Un utente ha il permesso di scrivere solo sui file pubblici di sua proprietà • Un utente ha il divieto di sostituire un file con una sua versione più obsoleta • Un utente ha l’obbligo di cambiare la propria password quando questa scade • Un utente segreto ha il permesso di leggere su un qualunque file non pubblico • Un utente segreto ha il permesso di scrivere su un qualunque file non pubblico • Un amministratore ha il permesso di sostituire un qualunque file con una sua versione più obsoleta • Un utente che non cambia la sua password scaduta (negligente) ha il divieto di compiere qualunque operazione • Un utente che non cambia la sua password scaduta (negligente) non ha discrezione di cambiarla Prof. Stefano Bistarelli - Sicurezza Informatica

  37. I mattoni dell’esempio • Utenti • Ruoli: utente, utente segreto, sistemista, utente negligente • Operazioni: leggere, scrivere, “downgrade”, cambio password • Modalità: obbligo, permesso, divieto, discrezionalità Prof. Stefano Bistarelli - Sicurezza Informatica

  38. Relazioni fra le modalità • Modalità base: Obbligatorio(x) • Permesso(x) = ¬Obbligatorio(¬x) • Vietato(x) = Obbligatorio(¬x) • Discrezionale(x) = ¬Obbligatorio(x) Prof. Stefano Bistarelli - Sicurezza Informatica

  39. Intersezione dei ruoli • Problema: un utente riveste più ruoli negligenti utenti utenti segreti amministratori Prof. Stefano Bistarelli - Sicurezza Informatica

  40. Inconsistenze di una politica • Contraddizione: Obbligatorio(x) ∧¬Obbligatorio(x) • Dilemma: Obbligatorio(x) ∧Obbligatorio(¬x) Prof. Stefano Bistarelli - Sicurezza Informatica

  41. Inconsistenze nell’esempio • Contraddizione da regole 3 e 7 • Un amministratore ha permesso e divieto di fare downgrade di un file • Dilemma da regole 8 e 9 • Un utente negligente ha l’obbligo sia di cambiare sia di non cambiare la propria password Prof. Stefano Bistarelli - Sicurezza Informatica

  42. Esercizio Trovare tutte le inconsistenze nell’esempio Prof. Stefano Bistarelli - Sicurezza Informatica

More Related