INFSO-RI Enabling Grids for E-sciencE Models for Security Vulnerabilities and Threats Yuri Demchenko Advanced Internet Research Group (AIRG) University of Amsterdam

INFSO-RI Enabling Grids for E-sciencE Outline Background: Addressing known security vulnerabilities From Vulnerability to Incident Existing classifications and models Proposed security threats classification and models

Enabling Grids for E-sciencE INFSO-RI Addressing Known Security Vulnerabilities Grid Operational Centers (and JSPG :-) know major security vulnerabilities –Those that are actually obvious  Reason why it happened? –We can expect more will be discovered when we apply regular security vulnerability analysis and risk assessment Approach for security/operational people? –Actively search for vulnerabilities OR wait until somebody will discover them and (mis)use (Already perceived) Problems –There is no common approach/model for analysing security vulnerabilities in Web Services and Grids –All security models and methodologies are complex and multifaceted  Grid is new but not unique – better learn from others’ expereince  Need some efforts and willinness to learn or to listen to experts

Enabling Grids for E-sciencE INFSO-RI Vulnerability-Incident life-cycle Vulnerability => Exploit => Threat => Attack/Intrusion => Incident Vulnerability is a flaw or weakness in a system's design, implementation, or operation and management that could be exploited to violate the system's security policy Exploit is a known way to take advantage of a specific software vulnerability Threat is a potential for violation of security, which exists when there is a circumstance, capability, action, or event that could breach security and cause harm Attack is an assault on system security that derives from an intelligent threat Incident is a result of successful Attack

Enabling Grids for E-sciencE INFSO-RI Basic steps in attacking methodology

Enabling Grids for E-sciencE INFSO-RI Known Vulnerabilities and Threats Classifications OWASP (Open Web Application Security Project) – –Developed in and industry adopted EVDL (Enterprise Vulnerability Description Language) –OASIS WG – Web Applications Security Threats Model by Microsoft – XML Web Services Security Vulnerabilities/Threats classification –Proposed in MJRA3.4 and updated in MJRA3.6

Enabling Grids for E-sciencE INFSO-RI Top 10 OWASP vulnerabilities A1 - Unvalidated Input A2 - Broken Access Control A3 - Broken Authentication and Session Management A4 - Cross Site Scripting (XSS) Flaws A5 - Buffer Overflows A6 - Injection Flaws A7 - Improper Error Handling A8 – Insecure Credentials Storage A9 - Denial of Service A10 - Insecure Configuration Management

Enabling Grids for E-sciencE INFSO-RI XML Web Services threats/ attacks classification (1) XWS1 – Web Services Interface probing –WSDL scanning, WSDL parameters tampering, WSDL error interface probing XWS2 – XML parsing system –Recursive XML document content, oversized XML document XWS3 – Malicious XML content –Malicious code exploiting known vulnerabilities in back-end applications, viruses or Trojan horse programs, malicious XPath or XQuery built-in operations, malicious Unicode content XWS4 – External reference attacks –Malicious XML Schema extensions, namespace resolution manipulation, external entity attacks

Enabling Grids for E-sciencE INFSO-RI XML Web Services threats/ attacks classification (2) XWS5 – SOAP/XML Protocol attacks –SOAP flooding attack, replay attack, routing detour, message eavesdropping, “Main-in-the-middle” attack XWS6 – XML security credentials tampering –XML Signature manipulation, secure XML content manipulation, Unicode content manipulation, XML credentials replay, application session hijacking XWS7 – Secure key/session negotiation tampering –Poor WS-Security implementation, poor key generation, poor key/trust management; weak or custom encryption

Enabling Grids for E-sciencE INFSO-RI Threats/Attacks grouping in interacting services

Enabling Grids for E-sciencE INFSO-RI Threats/Attacks grouping (1) WIA – “Wire” Intelligence Attacks –Network eavesdropping –“Man in the middle” (MITM) –Brute Force –Credentials compromise –Replay/Session hijack –XML/SOAP protocol MIA – Melifactor Initiated Attacks –Denial of Service (DoS) –Brute Force –Dictionary Attacks –WSDL probing UCA – User Credentials Attacks –Credentials theft –Credentials compromise –User impersonation

Enabling Grids for E-sciencE INFSO-RI Threats/Attacks grouping (1) SIA – Site Management Attacks –Configuration vulnerabilities –Improper Key/Trust Management –Improper Privilege Management –Improper Error Handling –Insecure audit/logging ESA – End Services Attacks –Resource misuse and quota violation –Malicious input –Dynamic XML –XML/SQL Injection –(XSS)

Enabling Grids for E-sciencE INFSO-RI Security models for interacting Grid/XWS services Requestor/User site security zones Service/Resource site security zones

Enabling Grids for E-sciencE INFSO-RI Requestor/User site security zones

Enabling Grids for E-sciencE INFSO-RI Service/Resource site security zones

Enabling Grids for E-sciencE INFSO-RI Example use of security models Collaboratory.nl project (CNL) Providing secure remote access to unique analytical equipment Job-centric security model for Open Collaborative Environment –Distributed security services model –Security context handling addressed –Trust model for distributed security services

Enabling Grids for E-sciencE INFSO-RI Authorisation Service operation in a CNL2 Demo system JNLP – Java Network Launch Protocol CHEF – Collaborative tool Surabaya – Collaborative Workspace environment Locations

Enabling Grids for E-sciencE INFSO-RI Security and trust issues in the OCE Job-centric security model TA – Trust Anchor; TR# - trust path from root (resource); RAM – Resource Allocation and Management; UserCT – User Collaborative Tools

Enabling Grids for E-sciencE INFSO-RI Trust relations in distributed access control infra Obtaining required permissions to perform requested action by the user: User => AuthN(HomeOrg.staff, Job.members) => => AuthZ(Member.roles, Policy.permissions) => => Resource.permissions Trust/credentials chain and delegation between major modules: User => => HomeOrg.staff(TA2) => Job.members => Member.roles => Role.permissions

Enabling Grids for E-sciencE INFSO-RI Summary and next steps Security vulnerabilities and attacks classification provides an input to further analysis of existing and to be discovered vulnerabilities Proposed Requestor and Resource security models need discussion and trial with analysing real middleware products –Need to be developed to cover case with the delegation Need some organisational form to proceed as an ad- hoc activity to target improving Grid middleware security

Enabling Grids for E-sciencE INFSO-RI Additional materials Users vs hackers Application security layers Host security components Implementation suggestions for OCE/CNL Job-centric security architecture

Enabling Grids for E-sciencE INFSO-RI Users vs hackers Users go regular route Potential hacker use any possible opportunity to bypass

Enabling Grids for E-sciencE INFSO-RI Application Security Layers Grid and application security must be build on solid base of lower layers Grid middleware constitutes Tier 3 layer and must protect actual applications from possible attacks

Enabling Grids for E-sciencE INFSO-RI Host security components Protocols and Ports that provides network access and communication services for applications. Common OS Services Files and Directories User Accounts and privileges Registries Auditing and Logging Patches and Updates management

Enabling Grids for E-sciencE INFSO-RI Trust relations in distributed Access Control Implementation suggestions for OCE/CNL security model –Root of trust and authority belong to the Resource –Trust anchor TA2 embedded into the Job Description is the main trust anchor shared between the resource and the customer.  In more business integrated model the signed order may contain TA1  Both TA2 and TA1 may have the same trust path to the root/resource –To become a shared trust anchor for the resource and the customer trust domains, the Order or JobDescription must contain mutually signed credentials/certificates –Although the main PEP operation assumes authorisation decision request from the trusted PDP, in general PEP may accept an AuthzTicket from other trusted/external PDP