An approach to Separation of Duties validation for MILS security - PowerPoint PPT Presentation

An approach to Separation of Duties validation for MILS security configurations Semen Kort, Dmitry Kulagin, Ekaterina Rudina Future Technologies Kaspersky Lab

The objectives    Discover the Describe how the Describe the situations requiring Separation of approach(es) to the cooperation of Duties may help in the validation of separated MILS keeping the main SoD requirement Domains properties provided fulfillment by MILS Platform

Kaspersky Security System on the MILS Platform

Security policy How the security policy addresses the ? concern of Separation of Duties on MILS platform? SoD requirement

Security policy Challenges ? • Validation of SoD without any regard to the policy implemented by Security Server • Formal definition of SoD requirement to validate • Acceptable complexity of the validation algorithm SoD requirement

Capability-based security policy CFG language Security configuration Challenges ? • Validation of configuration without any regard to the policy implemented by Security Server • Formal definition of SoD requirement to validate • Acceptable complexity of the validation algorithm SoD requirement

Security configuration • Associates security policies to the particular types of communication and security-related events • CFG file is compiled into the code of Security Runtime 7

levels: [“unclassified”, “confidential”, “secret”, “top-secret”] entity communicator { call in = allow; call out = allow; execute default = allow; mls.json } entity communicator { call in = allow; call out = allow; entity test { call in = allow; call in org.date.SetDate = mls_write; call out = allow; call in org.date.GetDate = mls_read; execute default = allow; execute default = mls_init(“top-secret”); } } entity test { call in = allow; call out = allow; execute default = mls_init(“unclassified”); execute mls(level) = mls_init(level); } simple.cfg advanced.cfg

Case 1 The approach The approach fits the following needs Verifies that the rights are transferred to Facilitates the separation of duties and subjects that do not have the conflicting the keeps the proper isolation of groups rights of subjects on the MILS platform MILS Domains may share the resources and cooperate, but we need the guarantees that the single Domain is incapable of overcoming the policy constraints and getting excessive privileges

Case 2 The approach The approach fits the following needs Verifies the monopoly access to the Facilitates the scenarios requiring critical resource for any Domain at any sequential actions on the same moment of time resource that are separated due to trustworthiness concerns MILS Domains may implement different actions but their coordination into sequence without the “trusted” coordinating domain is a challenge

Case 1

Capability-based security policy CFG language Security configuration Challenges ? • Formal definition of SoD requirement to validate • Acceptable complexity of the validation algorithm SoD requirement

Capability-based security policy CFG language Security configuration ? OpSSoD requirement RBAC OpSSoD Semi-formal SoD requirement for the definition requirement particular Role-based access control configuration

Capability-based security policy CFG language Security configuration ? OpSSoD requirement SoD requirement Role-based access control

Capability-based security policy CFG SPM metamodel language Security configuration CFG model in ? SPM OpSSoD requirement SoD requirement Role-based access control

KSS security configurations in terms of Schematic Protection Model KSS CFG SPM What concepts we consider How the model reflects these concepts Capability Ticket Capability type Type of the ticket ‘Call’ policies allowing the interaction of entities Link predicate Constraints on the rights transferred within capability Filter function ‘Execute’ policies / predefined rules for entities Can-create predicate Capability transfer/derive mechanisms Attenuation of privilege

Capability-based security policy CFG SPM metamodel language Security configuration CFG model in ? SPM OpSSoD requirement in SPM OpSSoD requirement SoD requirement Role-based access control

OpSSoD requirement in terms of Schematic Protection Model Resource Subject/Type1 Subject/Type2

Capability-based security policy CFG SPM metamodel language Security configuration CFG model in ? Criteria for SPM validation the OpSSoD OpSSoD for Security requirement configuration in SPM OpSSoD requirement SoD requirement Role-based access control

Criteria for validation the OpSSoD for Security configuration Check whether Create the the scheme is scheme Create “fully Check the acyclic according to unfolded” state criteria fulfillment (always CFG attenuating)

Capability-based security policy CFG SPM metamodel language Security configuration CFG model in ? Criteria for SPM validation Validation the OpSSoD process OpSSoD for Security requirement configuration in SPM OpSSoD requirement OpSSoD SoD requirement for the requirement particular Role-based access control configuration

Case 2

Capability-based security policy CFG language Security configuration Challenges ? In terms of SPM • The subject can't transfer the right for the monopoly access to the resource SoD Monopoly access to • The right can't be removed (the scheme is requirement resource transferred monothonic) between subjects

The new type of rights contained by capabilities  The Linear Rights • Only one subject may possess this right at every moment of time • When the capability with the linear right is revoked, this right will be given back to the parent The idea of linear rights allows addressing the requirements to the monopoly access to resources

Capability-based security policy CFG Linear Rights language Security configuration ? Validation of the Validation constraints related process to the use of simple/linear rights Simple rights SoD Monopoly access to requirement resource transferred between subjects

Linear rights  Main aspects The single linear right may be added to the scheme without the violation of already verified SoD properties Thus, we can combine the SoD aspect proven as in the Case 1 and fine-grained monopoly access to the resources where needed The linear right can’t be combined with the appropriate simple right. This constraint must be checked before applying the configuration

Future work  The open question: verification for the composition of the capability- based control with other policies  More types of Separation of Duties  More applications/case scenarios to verify

LET’S TALK? Kaspersky Lab HQ 39A/3 Leningradskoe Shosse Moscow, 125212, Russian Federation Tel: +7 (495) 797-8700 www.kaspersky.com