mils c compl plete s ete separa rati tion p n platf tform
play

MILS C Compl plete S ete Separa rati tion P n Platf tform orm - PowerPoint PPT Presentation

MILS C Compl plete S ete Separa rati tion P n Platf tform orm P Protec ecti tion n Profi file le MILS CSP PP Viola Saftig, Dr. Igor Furgel Telekom Security - T-SYSTEMS INTERNATIONAL GmbH Content/Agenda 01 Motivation 02 MILS CSP


  1. MILS C Compl plete S ete Separa rati tion P n Platf tform orm P Protec ecti tion n Profi file le MILS CSP PP Viola Saftig, Dr. Igor Furgel Telekom Security - T-SYSTEMS INTERNATIONAL GmbH

  2. Content/Agenda 01 Motivation 02 MILS CSP PP Overview 03 TOE Architecture 04 Assets 05 Roles 06 Security Requirements

  3. Motivation Question How to build up and operate devices with a mix of critical and of unknown (and untrustworthy) applications in a secure and reliable way? Possible approach – MILS security architecture Multiple Independent Levels of Security (MILS)  Based on the concepts of resource separation and controlled information flow.  Offering a secure decomposition of complex embedded systems into logically independent components.  Supports the coexistence of untrusted and trusted components. Challenge TOE (Target of Evaluation) may comprise very different system constellations. 3

  4. Motivation Common Criteria Protection Profile for MILS separation platform (MILS CSP PP) A generic, but clear description is mandated  for the components of a MILS system and  for the obligations during system integration, while determining the operational environment and selecting concrete components. 4

  5. Mils CS PP - Overview Target of Evaluation (TOE)  Special kind of operating system and underlying hardware platform.  Used as an integrated component in MILS systems.  May be used as part of embedded systems.  Can host user applications (e.g. operating systems) and system applications.  User applications can be malicious.  Controls usage of memory, devices, processors, and communication channels.  Separation of user applications.  Prevention of unexpected interference between user applications.  Enforces restrictions on the communication between user applications. 5

  6. TOE Architecture 6

  7. TOE Architecture 7

  8. TOE Architecture 8

  9. TOE Architecture 9

  10. Assets Primary assets Values being really important for the risk owner and to be protected by the TOE itself. Secondary assets TSF and TSF configuration data enforcing the System Security Policy (SSP) as defined by the System Integrator. Definitions  A system component is a system partition, system extension or an ODSP and contains user data supplied and approved by the system integrator.  A communication object is used for communication between partitions (object exposed to one or multiple partitions with access rights as defined in the configuration data). 10

  11. Primary Assets Description Generic Security Properties User partition content Confidentiality  User applications and/or data being executed and/or stored in a user partition  Integrity  Confidentiality  Communication object Content of a communication object and exchanged (received/read and sent/written) between  partitions Integrity content  Confidentiality System applications and/or data being executed and/or stored in a system component (a   System component system partition, a system extension or the on-board device support package). Integrity  content Confidentiality  Audit data Electronic records reflecting events to be audited.  Integrity  (optional) 11

  12. Secondary Assets Description Generic Security Properties Comprise physical memory space and allocated CPU time for each CPU  User partition resources Availability  Resources are assigned according to the SSP  Contains a set of security attributes assigned to a user partition (e.g. unique partition  User partition identity, flag indicating that the partition is a user partition, SSP enforcement data.) Confidentiality  shape Links its user partition resources and its user partition content  Integrity  Can contain security irrelevant data, e.g. information on optimising virtualised guests that is  not security relevant Memory space  Availability  Resources are assigned according to the SSP  Communication object resources Contains a set of security attributes assigned to a communication object (e.g. unique  Confidentiality  communication object identity) Communication object Integrity  Links its communication object resources and its communication object content shape  12

  13. Secondary Assets Description Generic Security Properties System component Availability  Comprises physical memory space and allocated CPU time for each CPU resources  Confidentiality  Resources are assigned according to the SSP  Integrity  System component shape Contains a set of security attributes assigned to a system component (e.g. unique identity, flag  Confidentiality  indicating that the partition is a system partition) Integrity  Links its system component resources and its system component content  Configuration data Confidentiality  Data used by the TOE to enforce the SSP  Integrity  System application API Availability (in the sense of  Interface to functions of the TSF available for system applications ‘executability’) only for  system applications 13

  14. Roles Description User application Any application within a user partition,  Allowed to use only the TOE user partition API  For each instantiation of this subject the TOE assigns a unique subject identity  System application Any application within a system partition, a system extension, or the on-board device support package (ODSP)  Only a system application in a system partition is allowed to use the TOE system partition API  Only a system application in a system extension is allowed to use the TOE system extension API.  Only a system application in the ODSP is allowed to use the TOE ODSP API  For each instantiation of this subject the TOE assigns a unique subject identity  System Integrator Person trusted to (re-)configure and integrate the TOE  This includes identifying system partitions and user partitions and assigning applications into partitions  System Operator Person trusted to (re-)install, stop, start, restart, or access (also physically) the TOE in the field  14

  15. Roles Description Attacker Threat agent (a person or a process acting on his/her behalf) trying to undermine the TOE security policy  The attacker especially tries to change properties of the assets having to be maintained according to the TOE security policy  The attacker is assumed to possess an at most high attack potential  Only attacks carried out by user applications are addressed (no physical attacks)  All attacks from other sources than user applications shall be averted by the TOE operational environment.  15

  16. Security Requirements Security Assurance Requirements (SAR)  Defining the scope and the rigour of the evaluator’s verification work.  This PP claims conformance to the CC assurance package EAL5 augmented by AVA_VAN.5.  Resistance against high attack potential. Security Functional Requirements (SFR)  To be enforced by the TSF.  Security functional groups are defined and allocated to the functional requirements.  SFRs which are always used together are grouped by “{}”.  SFRs whose fulfilling might need a direct support by the TOE hardware are tagged by HW. 16

  17. Security Requirements Security Functional Requirements (SFRs) Separation in space of User Data Protection (FDP) applications hosted in {FDP_ACC.2/AS.USER_PART_CONT, FDP_ACF.1/AS.USER_PART_CONT} HW, {FDP_ACC.2/AS.SYS_COMP_CONT,  different partitions from FDP_ACF.1/AS.SYS_COMP_CONT} HW, {FDP_IFC.2, FDP_IFF.1}, FDP_IFF.5 each other and from the Resource Utilisation (FRU) TOE operating system. FRU_RSA.2/AS.USER_PART_RES  Supported by: Identification and Authentication (FIA) FIA_UID.2  Security Management (FMT) all selected components of the class FMT  Protection of the TOE Security Functions (FPT) all selected components of the class FPT  17

  18. Security Requirements Security Functional Requirements (SFRs) Separation in time of User Data Protection (FDP) applications hosted in {FDP_ACC.2/AS.COMMUN_OBJ_CONT, FDP_ACF.1/AS.COMMUN_OBJ_CONT}, {FDP_IFC.2, FDP_IFF.1}, FDP_IFF.5,  different partitions from FDP_RIP.2 HW each other and from the Resource Utilisation (FRU) TOE operating system FRU_PRS.1, FRU_RSA.2/AS.USER_PART_RES  Supported by: Identification and Authentication (FIA) FIA_UID.2  Security Management (FMT) all selected components of the class FMT  Protection of the TOE Security Functions (FPT) selected components of the class FPT  18

  19. Security Requirements Security Functional Requirements (SFRs) Provision and User Data Protection (FDP) management of {FDP_ACC.2/AS.COMMUN_OBJ_CONT, FDP_ACF.1/AS.COMMUN_OBJ_CONT}, {FDP_IFC.2, FDP_IFF.1}, FDP_IFF.5  communication objects Resource Utilisation (FRU) FRU_RSA.2/AS.COMMUN_OBJ_RES  Supported by: Identification and Authentication (FIA) FIA_UID.2  Security Management (FMT) all selected components of the class FMT  Protection of the TOE Security Functions (FPT) selected components of the class FPT  19

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend