1. Security Architecture & Models “The security architecture of an information system is fundamental to enforcing an organization’s information security policy.”

2. Computer Architecture  CPU, control bus  Memory: cache, RAM, DRAM, ROM  CPU: Instruction cycle: fetch & execute Pipelining, CISC, RISC, Multi-tasking, Multi-Processing I/O: programmed I/O, DMA, Interrupts

3. Software  Languages 1GL: machine language 2GL: Assembly language 3GL: FORTRAN, BASIC, PL/1, C, etc 4GL: NATURAL, FOCUS, SQL 5GL: Prolog, LISP, other AI languages

4. Open & Closed Systems  Open: Vendor independent Designed & written by “outsiders” Subject to review & evaluation by outside parties not company insiders  Closed Vendor dependent Not typically compatible with other systems

5. Distributed Architecture  Migration from centralized to client/server User is also admin, programmer & operator Desktops can contain sensitive, at risk, info Users might lack security awareness Desktop can provide avenue into “trusted” networks Modems, PDAs, USB drives can be attached easily Downloading from Internet can produce disasters Desktops are hard to protect physically Lack of proper backup

6. Security mechanisms for Distributed Environments  Email & upload/download policies  Robust access controls (biometrics &/or 2 tier controls)  GUIs to restrict access to “real” system  File Encryption & cipher tools for email  Users with limited “rights”  Separation of processes into privileged & non-privileged  Lock desktops, enable tampering logging  Enable remote logging  Centralized backup

7. Protection Mechanisms  Protection Domain: execution & memory space assigned to each process  Abstraction ie objects & OOP  Security Labels: classification for access control  Security Modes: A system operates in different modes with users having different rights depending on the security label the object being processed has

8. Rings or layers of security  OS kernel is usually inner most circle  Processes & users are closer or further from the center depending on classification and need

9. Recovery Procedures  Should not provide opportunity for violations of system’s security policy  Fault-tolerant: computer system fails but network continues to opperate  Failsafe system: hardware or software failure causes “controlled” shutdown  Fail-soft or resilient: non-critical processing is discontinued but network or computer continues in degraded mode  Failover: switching to duplicate systems in case of failure

10. Assurance  Degree of confidence in the satisfaction of security needs.  Following slides provide an overview of guidelines & standards that help evaluate security aspects of a system

11. Assurance: Evaluation Criteria  Trusted Computer Evaluation Criteria (TCSEC)  Basic control objectives are: security policy, assurance & accountability  Assurance levels are: D (minimal protection), C (discretionary), B (manditory), & A (Verified)

12. Assurance: Certification & Accreditation  Formal methods provide for an authority that takes responsibility for system security  Certification: comprhensive eval of system security  Accreditation: format declaration

13. Certification & Accreditation  Responsibility (i.e. blame) requires Formal methods  Certification Comprehensive eval of technical & non-technical security features  Accreditation Formal declaration by Designated Authority stating that system is approved to opperate in particular security mode  Rechecked after defined period of time

14. U. S. Defense Accreditation Process  Phase 1: understand mission, environment, & architecture to determine security requirements  Phase 2: create SSAA an evolving, binding security agreement. SSAA becomes baseline security agreement  Phase 3: Validation: check compliance  Phase 4: Post Accreditation

15. U. S. Defense Types of Accreditation  Site: evaluates a single site  Type: evaluates an app or system distributed to a number of locations  System: evaluates a major app or support system

16. Systems Security Engineering Capability Maturity Mdl (SSE-CMM)  If you can guarantee process you can guarantee the product 1.Describes essential characteristics of security engineering process 2.Captures industry best practices 3.Accepted ways of defining practices and improving capability 4.Provides measures of growth in capability

17. SSE-CMM Security Engineering Process Areas Administer security controls Coordinate security Assess impact & security risk Monitor security posture Assess threatProvide security input Assess vulnerabilitySpecify security needs Build assurance argument Verifiy & validate security

18. Information Security Models  Used to formalize security policy  Three types of models 1.Access control models 2.Integrity models 3.Information flow models

19. Access control models  Access Matrix Access rights for subjects to objects  Take-Grant Model Directed graph to specify rights that a subject can take or grant from or to another subject  Bell-LaPadula Model Department of Defense Deals only with confidentiality not integrity or availability

20. Access Matrix Columns provide ACL for each object Subject/Ob ject File: Income File: Salaries Process: Deductions Print Server: A JoeReadRead/WriteExecuteWrite JaneRead/WriteReadNoneWrite Process: Check Read ExecuteNone Program: Tax Read/Write CallWrite

21. Directed Graph Subject A Object B Subject C Subject/Object D Grant rights to B Including grant right A has rights Y to D Grant subset of Y on D

22. Bell-LaPadula Model  Simple Security Property Reading of info by subject of lower sensitivity from object of higher not permitted Writing of info by subject of higher to object of lower not permitted Uses Access Matrix to specify discretionary access control

23. Integrity Models  Sometimes integrity is as or more important than confidentiality  Biba Integrity Model  Clark-Wilson Integrity Model

24. Biba Integrity Model Three Goals: 1.Data is protected from modification by unauthorized users 2.Data is protected from unauthorized modification by authorized users 3.Data is internally & externally consistent

25. Biba Integrity Model Axioms High Integrity Level Medium Integrity Level Low Integrity Level Read OK (simple integrity axiom) subject Invoke Not ok Write ok (integrity axiom)

26. Clark-Wilson Integrity Model  Real world model  Constrained data item (CDI): object whose integrity is to be preserved  Integrity Verification Procedure: confirms that all CDIs are in valid states of integrity  Transformation Procedure: assures that well formed manipulations are used to change CDIs  Unconstrained data item

27. Information Flow Models  Based on a state machine  Consists of objects, state transitions, and flow policy  Objects are constrained to flow only in the directions permitted by the security policy

28. Confidential (Project X) Confidential (Task 1, Project X) Confidential (Task 2, Project X) Unclassified Confidential

29. Composition Theories  Systems are usually built by combining smaller systems  Therefore must consider whether security of component systems are maintained when combined into larger systems  Types of constructs Cascading: input to one sys is from another Feedback: loop one to second back to one Hookup: system that communicates with both internal & external systems