1 Update on the Vulnerability Assessment Effort Elisa Heymann Computer Architecture and Operating Systems Department Universitat Autònoma de Barcelona

First Principles Vulnerability Assessment Understanding the System Step 1: Architectural Analysis –Functionality and structure of the system, major components (modules, threads, processes), communication channels –Interactions among components and with users

CE Host authZ service Host PDP WN Host PEP Server WN job gLExec PAP Admin Tool (Edit Policy) Administrator a LRMS WMS CREAM User (UI) 1a1a RB Host 1b1b Argus 1.2 Architecture PAP 7 8 D’ E’ PAP (Policy Administration Point) → Manage Policies. PDP (Policy Decision Point) → Evaluate Authorization Requests. PEP (Policy Enforcement Point) → Process Client Requests and Responses. B A C’ Admin data-flow User data-flow F’ DtDt HTTPS PEP Client (Lib) Communications among PAP, PDP, and PEP Server via HTTPS CLI EtEt /etc/init.d/pdp reloadpolicy /etc/init.d/pepd clearcache FtFt 10b Run jobExit gLExec OS privileges userbatch user External Component Administrator & root root

User: X’ = Optional steps Xt = Periodic steps 1.User submits a job described as a JDL expression. 2.CREAM receives a job execution request from WMS (1a) or the User (1b) directly. 3.CREAM sends the job execution request to the LRMS. 4.LRMS sends the job to the WN for its execution. 5.WN sends an authorization request to gLExec, and gLExec interacts with PEP Server using an LCMAPS plug-in which uses the PEP Client library to check if the mapping request can be satisfied. 6.PEP Client sends the XACML request to the PEP Server. 7.PEP Server sends the authorization request (XACML) to PDP for evaluation. 8.PDP evaluates the authorization request and sends the response to PEP Server. 9.PEP Server sends to PEP Client the authorization response which can be allowed (10a) or denied (10b). 10.gLExec runs job using local identity only if the authorization response is allowed. Admin: A.Administrator edits policies using the command line interface (CLI). B.PAP Admin Tool writes policies and policy sets and make them available at PAP. C’.Administrator reloads policies since Argus updates the policies in regular intervals. D’.PDP sends a retrieve policies request to PAP. E’.PAP sends policies (XACML) to PDP. F’. Administrator sends a clear cache request to PEP Server for clearing the response cache. Dt.PDP connects periodically to the remote PAP to refresh the repository policy. Et.PAP sends the policies (XACML) to PDP. Ft.PEP Server clears periodically its cache, since PEP Server keeps a short response cache. Argus 1.2 Architecture

First Principles Vulnerability Assessment Understanding the System Step 2: Resource Identification –Key resources accessed by each component –Operations allowed on those resources Step 3: Trust & Privilege Analysis –How components are protected and who can access them –Privilege level at which each component runs –Trust delegation

authZ service Host (PAP Component) conf lib logs TRUSTED_CA etc/ grid_security pap_ configuration.ini pap_ authorization.ini hostcert.pem host has key signed, hostkey.pem Argus 1.2 Resources Readable Owner World certificates PAP logging bin pap-admin repository sbin pap- standalone.sh pap- deploy.sh XML Policies OS privileges userbatch user External Component Administrator & root root

authZ service Host (PDP Component) conf lib logs TRUSTED_CA etc/ grid_security pdp.ini hostcert.pem host has key signed, hostkey.pem Argus 1.2 Resources certificates sbin env.sh logging.xml Readable Owner World pdpctl.sh PDP Repository policy OS privileges userbatch user External Component Administrator & root root

authZ service Host (PEP Server Component) conf lib logs TRUSTED_CA etc/ grid_security pepd.ini Argus 1.2 Resources sbin env.sh logging.xml Readable Owner World pepdctl.sh hostcert.pem host has key signed, hostkey.pem certificatesgrid-mapfilegroupmap file gridmapdirvomsdir PEP Server Cached Policies OS privileges userbatch user External Component Administrator & root root

First Principles Vulnerability Assessment Search for Vulnerabilities Step 4: Component Evaluation –Examine critical components in depth –Guide search using: Diagrams from steps 1-3 Knowledge of vulnerabilities –Helped by Automated scanning tools

First Principles Vulnerability Assessment Taking Actions Step 5: Dissemination of Results –Report vulnerabilities –Interaction with developers –Disclosure of vulnerabilities

11 Vulnerability Report ›One report per vulnerability ›Provide enough information for developers to reproduce and suggest mitigations ›Written so that a few sections can be removed and the abstracted report is still useful to users without revealing too much information to easily create an attack.

12 Categories of Vulnerabilities ›Design Flaws –Problems inherent in the design –Hard to automate discovery ›Implementation Bugs –Improper use of the programming language, or of a library API –Localized in the code ›Operational vulnerabilities –Configuration or environment ›Social Engineering –Valid users tricked into attacking Occur about equally

13 Response to Vulnerabilities ›Identify a team member to handle vulnerability reports. ›Develop a remediation strategy: –Study the vulnerability report. –Use your knowledge of the system to try to identify other places in the code where this might exist. –Study the suggested remdiation and formulate your response. –Get feedback from the assessment team on your fix – very important for the first few vulnerabilities. ›Develop a security patch release mechanism. –This mechanism must be separate from your release feature/upgrade releases. –You may have to target patches for more than one version.

14 Response to Vulnerabilities Develop a notification strategy: ›What will you tell and when? ›Users are nervous during the first reports, but then become your biggest fans. ›Often a staged process: 1.Announce the vulnerability, without details at the time you release the patch. 2.Release full details after the user community has had a chance to update, perhaps 6-12 months later. ›Open source makes this more complicated! The first release of the patch reveals the details of the vulnerability.

15 Software to Assess ›gLite –VOMS Admin –Argus 1.2 –gLexec 0.8 –VOMS Core –CREAM: Computing Resource Execution And Management –WMS: Workload Management System

16 Software to Assess ›Unicore –TSI: The Target System Interface –Gateway

17 Current Status ›VOMS Admin : done! ›Java, JSP y javascript ›38 KLOC ›2.5 months of work

18 Current Status ›gLexec 0.8: done! ›C ›13 KLOC ›5 months of work

19 Current Status ›Argus 1.2: done! ›Java, C, scripting languages ›42 KLOC ›5 months of work ›No vulnerabilities found. ›Report on what was assessed and why Argus worked fine.

20 Were are we now ›VOMS Core 2.0.2: –Vincenzo Ciaschini & Valerio Venturi –C: –C++: –exp: 7955 –java: 7754 ›Started: May 2011 ›Expected duration: 6 months

21 Vulnerability Assessment Apply FPVA to relevant EMI Middleware –Assess the SW –Generate vulnerability reports A vulnerability is considered only when we produce an exploit for it.

22 Update on the Vulnerability Assessment Effort Elisa Heymann Computer Architecture and Operating Systems Department Universitat Autònoma de Barcelona