1/14 RAdAC (Risk Adaptable Access Controls) A New Emerging Security Approach Salvatore Del Popolo University of Trento Department of Information and Communication Technology Index 2/14 A New Information Philosophy RAdAC: Its Main Features The Prototype System Conclusion References Necessity Of Change 3/14 GIG: Global Information Grid architecture How systems should interact Changing in philosophy New Information Dissamination Policies >From static to dynamic policies Influenced by: Situational factors Environmental emergencies Groups of people IT components Seasons of year Econimic crisis Sanitary epidemies International police activities Form "Need to Know" to "Need to Share" - 1 4/14 >From rigid to flexible systems No more: too few privileges or too many privileges Increase interoperability Garanteeing flowing information Exmaple: A storm (A National Crisis) Hundreds of people to help Various entities need to share informations Police Fire brigades Hospitals Volunteers Sharing data is vital How do systems react? Which policies do they apply? From "Need to Know" to "Need to Share" - 2 5/14 Security remains a critical aspect Need to share does not mean no rules, no controls, no constraints whoever does whatever he wants It is not an ideal world Managing information means acquiring power Example: A Bank Complete distruction of data Although huge money.s amounts ... no future for the Bank Sharing information could mean no fairness From "Need to Know" to "Need to Share" - 3 6/14 MAIN IDEA In our world information is VITAL and CRITICAL AIM TO ACCOMPLISH sharing information and possibly increase security of existing systems MAIN PROBLEM Available architectures NOT ABLE TO ACCOMPLISH THESE AIMS Although systems implementing DAC Discretionary Access Controls not flexible enough to dynamically adapt to changing policies RAdAC - 1 7/14 (Risk Adaptable Access Controls) A suitable architecture to the desired system RAdAC.s Characteristics A RAdAC system must be able to: Define various policies Flexibly enforce or loosen policies Applying policies as the risk changes It.s difficult to: Define various policies Flexibly applying them RAdAC - 2 8/14 Key points: Static and dynamic factors: distance, bandwidth Decisions influenced by perceived risk: storm Access policies, necessity of revocation Correctly implementation of MAC (Mandatory Access Control) System always under subjects and objects control Security decisions based on security informations Security policy must be under a central control Necessity of flexibility: Enforcements and revocations must adapt to the changing situation RAdAC - 3 9/14 RAdAC is not easy to completely implement No systems succeed in accomplishing this aim An example: Flask Technology Flask is an acronym for Flux Advanced Security Kernel One fundamental basic concept: Separation of policy from mecanism Three main components: Security Server - Contains and defines policies Object Manager - Applies policies on objects AVC - Access Vector Cache The first and second component are really important Flask and SELinux - 1 10/14 SELinux - Secure-Enhanced Linux On which has been applied Flask Technology The creation of a RAdAC prototype system Prototype: Implementing policies on viewing xml-based documents We can identify various components Document server Security policies on documents Document clients Policies on documents. viewers Network security server Security policies on the network Risk knob Perception of risks and changing policies Flask and SELinux - 2 11/14 How the system works Clients and server connected through a secure network Client desiring to view a document 1. Authorized by the network security server 2. Authorized by the documents server 3. The viewers apply the policies regarding documents Servers and clients apply their regarding policies Each component does the least Security is enforced Flask and SELinux - 2 12/14 If the risk knob perceives a change in risk A new policy is applied and each system component is instructed consequently Not considering the various policies: Directly connected to the aspects seen so far The prototype demonstrated: 1. Dynamically and securely modifying policies 2. According to risk perception 3. Increase privileges and eventually revoke them Conclusion 13/14 At the moment this project is just a prototype It requires more work to become a usable solution Specifically: Securing windowing environment Vulnerabilities inside the viewer system Reducing work for initial policy configuration Writing additional policies Applications to handle network policy changes Automated way to support policy changes Interfacing the system with sensors Support real applications An important aspect Open source code Everyone can test it and possibly Improve it References 14/14 Flask http://www.cs.utah.edu/flux/flask/ SELinux http://selinuxnews.org http://selinux.sourceforge.net http://selinux-symposium.org http://www.nsa.gov/selinux Book: SELinux by Example (Frank Mayer et al, Prentice Hall, 2006)