Docstoc

g-0

Document Sample
g-0 Powered By Docstoc
					Security & Trust
 for the Grids
   Syed Naqvi
IT Security Group
  naqvi@enst.fr
From tele-communicare to Telecommunications
                       www.enst.fr




 22 November 2005   Security & Trust for the Grid   2
In 1904 …




Edouard Estaunié


“J'ai dû ajouter un
mot nouveau à un
glossaire déjà trop
riche …”


“I needed to add a
new word to an
already too rich
glossary …”           Courtesy of Bibliothèque Nationale de France
     Security Research Projects …
National (RNRT)                                  European Projects (IST & ITEA)
–   ICARE : Trusted Infrastructures, PKIs         – AMBIENCE : Security in a mobile
–   SWAP : WAP Security                             world, ambient intelligence
–   MMQoS : Security, Mobility and QoS            – BRIC : Audiovisual watermarking
–   ANAIS : Security of Professional              – SEINIT : Infospheres Security
    Mobile Radio                                  – BUGYO : Telecom Infrastructure
–   INFRADIO : Security on a campus                 protection
    and of infospheres in meshed                  – ACIP : Critical Infrastructure
    networks                                        protection
–   EPIS : Smart card security E2E with           – DESEREC : Security of Large
    IPv6                                            scale Resilient networked systems
–   RESODO : Security of domestic                 – SECOQC : Security of Quantum
    networks                                        Networks
–   AQUAFLUX : Mediametry                         – EURONGI : Trust in the next
    Watermarking                                    generation of Internet
–   ARTUS : Augmented reality marking             – VIPBOB : Cryptographic protocol
                                                    with biometric data.
 22 November 2005             Security & Trust for the Grid                      4
                                                   www.seinit.org




22 November 2005   Security & Trust for the Grid             5
Introduction
                         Need of Encryption
                                                                                Receiver
                 Sender

                                          Plaintext


                                     Defence from:
                                            Active             Active       Plaintext, P
           Plaintext, P
                             Passive       Intruder,          Intruder,
                            Intruder,     Can change          Can insert
                           only listens    message             message
           Encryption                                                       Decryption
Key                                                                                            Key
            Method                                                           Method
 K                                                                                              K
             Ek(P)                                                            Dk(C)


         Ciphertext, C                                                     Ciphertext, C


                                           Network
      22 November 2005             Security & Trust for the Grid                           7
                        Encryption
• Text is converted to ciphertext by use of an
  algorithm and key
    – Algorithm is publicly known
    – Key is held private

• Three Main Categories
    – Secret Key (symmetric cryptosystem)
       • single key is used to encrypt and decrypt information
    – Public/Private Key (asymmetric cryptosystem)
       • two keys are used: one for encryption (public key) and one
         for decryption (private key)
    – One-way Function (hash functions)
       • information is encrypted to produce a “digest” of the original
         information that can be used later to prove its authenticity

22 November 2005          Security & Trust for the Grid                   8
       Symmetric Key Encryption




22 November 2005   Security & Trust for the Grid   9
      Asymmetric Key Encryption




22 November 2005   Security & Trust for the Grid   10
      Hash Function




22 November 2005   Security & Trust for the Grid   11
   Certificates – X.509 Standard
                                                               Version

                                                           Serial Number

                                                         Signature Algorithm

                                                            Issuer Name
                   x509 v3 Bodypart
                                                               Validity
       X.509
     version 3
     Certificate                                            Subject Name
                   Signature Algorithm
                                                         Subject Public Key

                    Signature of CA                     Issuer Unique ID (v2)
                    Digital
                    Signature                           Subject unique ID (v2)

                                                           Extensions (v3)


22 November 2005        Security & Trust for the Grid                            12
22 November 2005   Security & Trust for the Grid   13
                    Kerberos Tickets
 Domain Authentication and Resource Access
                    1. Request a ticket for TGS
                                                                        Authentication
                             2. Return TGT to client
                                                                        Service (AS)

                   3. Send TGT and request for ticket to \\AppServ
                                                                           Ticket
                    4. Return ticket for \\AppServ                        Granting
Kerberos
                                                                          Service
 client      5. Send session ticket to \\AppServ                          (TGS)
             6. (Optional) Send confirmation of identity to client



                                                                (KDC)

                     \\AppServ

22 November 2005                Security & Trust for the Grid                            14
Security & Trust Challenges
Security & Trust for the Grid   16
               Technology Evolution
                               Customer                                  Vendor
                                                 Orders, Payments

                               Computer                                 Computer
• Static Cooperation                                  Invoice, Price
                                                     notices, updates
  – Electronic Data Interchange (EDI)

• Dynamic Cooperation
  – Internet

• Dynamic Collaboration
  – Peer-to-Peer (P2P), Web Services (WS)

• Dynamic Resource Sharing
  – Computational Grid
 22 November 2005    Security & Trust for the Grid                           17
22 November 2005   Security & Trust for the Grid   18
Lorch M., Kafura D., Grid Community Characteristics and their Relation to Grid
Security, Technical Report TR-03-20, Computer Science, Virginia Tech., June 2003

    … more than half of the grid community members believe that
    existing grid security solutions do not provide adequate services
    for collaborative grid communities. The reasons given ranged
    from the lack of an underlying threat model to the complexity
    and expense of inter-site trust relationships that are currently
    required.


Connor D., Grid Computing Hits Security Gridlock, Network World Fusion online
magazine, 06 October 2002
    … adoption of global grids, where companies share hardware
    and software resources to accomplish a computational goal,
    has been slowed because of security concerns and a lack of
    standards.

    22 November 2005            Security & Trust for the Grid                   19
                   Challenges
•   Interoperability
•   Trust Management
•   Dependability/Trustworthiness
•   Usability
•   Robustness/Resilience/Survivability
•   Secure Delegation
•   Bootstrapping
•   Mobility
22 November 2005    Security & Trust for the Grid   20
22 November 2005   Security & Trust for the Grid   21
                   Challenges
•   Interoperability
•   Trust Management
•   Dependability/Trustworthiness
•   Usability
•   Robustness/Resilience/Survivability
•   Secure Delegation
•   Bootstrapping
•   Mobility
22 November 2005    Security & Trust for the Grid   22
                         Problems
• There is no benchmark to facilitate the development of
  grid security solutions

• The range of existing grid simulators (OptorSim,
  ChicagoSim, SimGrid, GridSim, EDGSim, GridNet, …)
  does not provide any support for the simulations of
  security services
    – Attack pattern, response time, recovery delay, …

• Developers are used to rely on the future patches
    – Fix the vulnerabilities AFTER their exploitation


22 November 2005          Security & Trust for the Grid    23
                          Problems
• However, there are some GENUINE problems too!
    – The scale of the grid does not permit us to exactly identify all the
      risks associated with it.

    – We can not foresee the exact level of the grid security services
      due to the dynamic nature of its applications.

    – There is no widely accepted and deployed technique that can
      measure the quality of grid security services.

    – Different countries have different electronic/cyber laws (e.g.
      copyright, intellectual property rights, …), which makes it difficult
      to deal with security breaches in transfrontier grid applications.



22 November 2005           Security & Trust for the Grid                  24
                   Observations …
… in the evolution of computational grids, security threats
were overlooked in the desire to implement a distributed
high performance computational system.

… the main reason for the vulnerability is the fact that grid
technology has been little used except by a certain kind of
public (mainly academics and government researchers).
This public benefit greatly from being able to share resources
on the grid, and have no intention of harming the resource
owners or fellow users. Thus there was no need to address
security in depth!


22 November 2005        Security & Trust for the Grid            25
State of the Art
              The GLOBUS Project
• Security
    – to provide authentication, delegation and
      authorization
• Information Services
    – to provide information about Grid services
• Data Management
    – involves accessing and managing data
• Resource Management
    – to allocate resources provided by a Grid
22 November 2005    Security & Trust for the Grid   27
          Security – Authentication
• Grid Security Infrastructure (GSI)
    – Based on public-key encryption technology (using X.509
      certificates) and SSL.

    – Define uniform authentication and authorization
      mechanisms that allow collaborating sites to accept
      credentials while retaining local control.

    – Each user has a Grid id, a private key, and a
      certificate signed by a Certificate Authority (CA).



22 November 2005         Security & Trust for the Grid         28
              Security – Delegation
• GSI supports a number of features that a
  grid user requires
    –   Authentication using a single-sign-on mechanism.
    –   Delegation through proxies.
    –   Integration with local security systems.
    –   Trust based relationships


• The GSI implementation in Globus adheres
  to the IETF GSS-API standard

22 November 2005         Security & Trust for the Grid     29
           Security – Authorization
• GSI handles authentication, but authorization
  is a separate issue
• Authorization issues:
    – Management of authorization on a multi-
      organization grid is still an interesting problem.
    – The grid-mapfile doesn‟t scale well, and works
      only at the resource level, not the collective level.
    – Large communities that share resources
      exacerbates authorization issues, which has led
      us to CAS…
22 November 2005      Security & Trust for the Grid       30
                   UNICORE Security
• Mutual Authentication (between Gateway/NJS and User)
  using X509 Certificates.

• No proxy certificates, no generalised delegation.

• Authorisation performed by the NJS using the UUDB
  Interface. (So authorisation is (potentially) moved away
  from the target system.)

• Separation of consigner and endorser: only a user can
  endorse a job; an NJS or a user can consign a job.



22 November 2005       Security & Trust for the Grid         31
                   UNICORE Security
• The signed AJO is sent to an NJS as a serialised Java
  object, via UPL (each AbstractJob component is
  signed).

• This model ensures no tampering with multi-Vsite jobs
  by intermediate NJSs.

• The user‟s private key never leaves the encrypted
  keystore on his/her workstation.

• At no point is any private key which could be used to
  impersonate the user (for any lifetime) ever created
  on a remote resource.

22 November 2005       Security & Trust for the Grid      32
      Secure Highly Available
     Resource Peering (SHARP)
• A “policy server” controls when, where, and to what
  extent users can access grid resources.

• Provides a construct to represent cryptographically
  protected resource “claims” promises or rights to control
  resources for designated time intervals together with
  secure mechanisms to subdivide and delegate claims
  across a network of resource managers.



22 November 2005     Security & Trust for the Grid        33
      Secure Highly Available
     Resource Peering (SHARP)
• “resource peering”: sites may trade their resources with
  peering partners or contribute them to a federation
  according to local policies.

• Separation of claims into “tickets” and “leases” allows
  coordinated resource management across the system.

• Introduces mechanisms for controlled, accountable
  “oversubscription” of resource claims as a fundamental
  tool for dependable, efficient resource management.


22 November 2005     Security & Trust for the Grid          34
                   SHARP Security
• ensures accountability
    – Protects sellers
         • Makes sure everyone gets paid
         • No one is unfairly held accountable
    – Protect buyers
         • Sold Resources are available with high probability


• But not
    – Confidentiality: Easy to see what my seller was issued and who
      else held the ticket
    – Authentication : Part of negotiation process
    – Trust : Tracking seller‟s overbooking practices left to applications


22 November 2005            Security & Trust for the Grid               35
                        Kerberos

• Some Grids use a Kerberos GSS-API.
    – As far as tools and APIs go, this is not visible.
      (That‟s the point of GSS-API!)
    – However, it is NOT interoperable with GSI
      based versions of the Globus Toolkit
    – Various differences of Kerberos vs. GSI:
         • The security files created “under the covers” are
           different
         • Different commands to login, logout, etc.

22 November 2005        Security & Trust for the Grid          36
Security Management = Babel Tower ?




 22 November 2005   Security & Trust for the Grid   37
Our Vision …
• Grid-specific Security Solutions
    – Keeping in mind the particular nature of the grid.
    – Huge bunch of nodes, dynamic creation of VOs, …

• Virtual Paradigm for the Grid Security Services
    – To absorb the heterogeneity of the underlying security architectures.
    – Implementation independent set of security services that can provide
      complete abstraction of its underlying technologies.

• Configurable set of the Security Services
    – To enable different users to invoke the set of security services that
      matches their requirements.
    – This is an extension of the vision of OGSA Security Model.
       • OGSA Security Model defines security as services – we can
         extend this vision to security as configurable services.
• Strictly follow the standard security practices
    – To come out of the undeclared „state of emergency‟
    – To handle the security issues with more organized pattern
       • Risks analysis, evaluation criteria, simulations, …
 22 November 2005           Security & Trust for the Grid                39
                       Virtualization
• The secure interoperability between VOs demands interoperable
  solutions using heterogeneous systems.
• Virtualization permits each participating end-point to express the
  policy it wishes to see applied when engaging in a secure
  conversation with another end-point.
• Policies can specify supported authentication mechanisms, required
  integrity and confidentiality, trust policies, privacy policies, and other
  security constraints.




22 November 2005           Security & Trust for the Grid                  40
               Security of the Ambient Intelligence : ecology of virtual ontologies (V2V)
                                  Management of global security, Transparency

                                                        A virtual community

Security of non functional properties : architecture, mobility, configurability, QoS, …




                                                                        Logical entities
 Security of functional objects : centralized trusted infrastructures (PKI, DNS, …)
                                                     Responsibility, Accountability




                                                                      Physical entities

22 November 2005                 Security & Trust for the Grid                            41
        Pluggability/Configurability
• Pluggable Security Services (PSS) requirements
  include:

    –   Definition of standard and flexible interfaces
    –   Integration at application layer
    –   Coordinated invocation of services
    –   Usable by users and services
    –   Simultaneous use of multiple services
    –   Support for future enhancement
    –   Optimization for various communication links
    –   Provision of real-time invocation features
    –   Use of standard programming interfaces

22 November 2005        Security & Trust for the Grid    42
      PSS Architectural Overview




22 November 2005   Security & Trust for the Grid   43
Coordination Service Architecture




22 November 2005   Security & Trust for the Grid   44
• Application/Client Interface
   – Authenticates user/application
   – Facilitate communications
                                               Security Broker
• Configuration Daemon
   – Accepts machine independent,
     abstract configuration request
   – Interacts with the coordination
     service
• Security Services Handler
   – Absorbs the diversity of security
     mechanisms
• Protocol Mapping
   – Contains the list of supported
     protocols
• Security Architecture Interface
   – Consists of socket modules to plug various security services.
  22 November 2005          Security & Trust for the Grid            45
VIPSEC : VIrtualized and Pluggable SECurity Services
 VIPSEC Model


       Local                                               CA          Access
     Resources                                                         Policy

                                   Mapping
                                    Server

                    Attribute                                          Target
       User                                                           Resources
                     Server


  User Domain                                                   Target Domain


 22 November 2005          Security & Trust for the Grid                          46
• In this architecture
   – New users or groups may be introduced quickly (scalability) as the
     security services layer harmonizes (virtualizes) the diverse security
     mechanisms of participating nodes and there is no restriction of
     specific communication or security requirement.
   – The handling of privileges provided to a group or individual can be
     easily managed as it employs role based access control (RBAC).
   – Isolation of applications layer from the core security architecture layer
     enhances the protection of the private data including authentication
     data.
   – Agreed security features could be implemented by making
     corresponding adjustments in the security broker layer.
   – The intermediary architecture could be employed to delegate actions;
     however, there is a need to shun the cloning of credentials as they
     could be exploited.
   – The attribute server could be employed to place limits on the overall
     amount of resources consumed by particular user or group. These
     limits are generally defined in the access policy of the target domain.
   – The confidence of the resource providers can be gained by offering
     them a number of pluggable security services. They can easily
     incorporate additional security features that assure them that their
     resources could neither be exploited nor be misused; and in the case
     of any misuse a chain of accountability could be established.
  22 November 2005           Security & Trust for the Grid                47
                    Security Policy
• Local Security Policy (PL)
    – Application policy, Access Control Policy, Data Integrity Policy,
      Authentication Policy, Encryption Policy

• Global Security Policy (PG)
    – Defines general security policy
    – Provides abstraction (virtualization) of all PLs

• Features
    –   Flexible policy-based access control mechanisms
    –   Inter-domain access control policies
    –   Secure group communication
    –   Delegation mechanisms to support scalability to large numbers
        of resources and users

22 November 2005           Security & Trust for the Grid                  48
                   Trust Management
• The problematic is:
    – How different nodes can trust unknown infrastructure with their
      private data ?
    – How a computing infrastructure can trust a node which is
      seeking access to its resources ?

• Definition of trust relationships between two nodes when
  there exist
    – Direct trust relationships within a single domain
    – Indirect trust relationships across multiple domains

• Dynamic establishment of trust relationships where any
  node can join and leave anytime and anywhere
22 November 2005          Security & Trust for the Grid                 49
• To establish trust among different nodes:
    – Instead of having a single value representing the trustworthiness
      of a node, the value should be broken into separate attributes
    – Each attribute represents a confidence, and each confidence
      represents a characteristic of a node from which trust can be
      synthesized

• There are varying forms of trust:
    –   We can trust a node to be accurate
    –   We can trust a node to complete tasks reliably
    –   We can trust nodes to return data quickly
    –   …

• These attributes form a virtual plane to link the resources,
  users (individuals and services) and the applications
    – This relationship signifies that there is not a fix form of trust among
      the various entities
    – It allows the greatest flexibility from one entity to the other.
22 November 2005           Security & Trust for the Grid                 50
• From the Functional Point of View:
    – These attribute certificates will be used in compliment with identity
      certificates
    – Like identity certificates are used to verify the identity of an entity
      in a highly anonymous environment, the attribute certificates will
      be used to determine the trustworthiness of an entity in an
      uncertain environment




22 November 2005           Security & Trust for the Grid                  51
            Security Bootstrapping
• The Resurrecting Duckling Policy Model
    – Secure Transient Association
         • exchange of a shared secret during physical contact (pairing)
           representing a master-slave relation between the devices.
    – Default Policy
         • the master device can access all services of the slave device; no
           other device is allowed to use services.
    – Shortcomings …
         • pair-wise master-slave relations between devices introduce
           dependencies between devices that limit the usability and are prone
           to loss of devices.
         • the model does not suggest how the credentials to represent these
            relations could be described in the policy in an authentic way.

22 November 2005              Security & Trust for the Grid                    52
• Our approach to address these shortcomings
   – ownership model
       • builds real peer-to-peer security relations between all devices owned by
         the same user and thereby strictly defines what devices that are trusted
   – security policy
       • defines relations to other devices, assigns rights to security relations, and
         supports authentic key exchange.
   – Privacy of information and resources
       • use of pseudonyms and secure service discovery protocols are
         emphasized
            – to provide the presence of devices only on a need-to-know basis
   – Usability
       • the important aspect is the „ease of use‟ because a user can not be
         expected to configure everything.

• We consider security bootstrapping as a first step towards the
  ambitious goal of self-configuration in the dynamic networked
  systems.
  22 November 2005              Security & Trust for the Grid                     53
              Security Negotiations
• Establishment of secure session between the endpoints
    – allows the endpoints to negotiate security requirements
    – supports end-to-end and/or hop-to-hop security associations
    – broadens applicability to general networked environments

• Security negotiations are carryout by the Security Broker
    – mediates between applications and the security services
    – employs a security services handler to absorb the heterogeneity
      of the underlying security services and to provide a homogeneous
      interface to the upper layer.

• Invocation of a set of optimal security services is possible

22 November 2005         Security & Trust for the Grid              54
Security of the Security Architecture
 • Determines if the security architecture can meet the
   security demands of an active and determined attack

 • The various steps we have taken to assure the security
   of the security architecture:
     –   Basic Design and Documentation
     –   Module Interfaces
     –   Authorized Roles and Services
     –   Physical Security
     –   Software Security
     –   Operating System Security
     –   Self Testing

 22 November 2005         Security & Trust for the Grid     55
                    Extension of OGSA
• The Open Grid Services Architecture (OGSA) security model
  casts security functions as OGSA services
   – allows well-defined protocols and interfaces to be defined for these
     services;
   – permits an application to outsource security functionality by using a
     security service with a particular implementation to fit its current need.


• We extend the OGSA concept of „Security as Services‟ to
  „Security as Pluggable Services‟
   – permits the evolution of security infrastructure with less impact on the
     resource management functionalities
   – permits the users and stakeholders to configure the security
     architecture according to their requirements and satisfaction level.
 22 November 2005           Security & Trust for the Grid                 56
• We add some handler modules into OGSA container to extend
  its functionalities
   – the service request comes into the container through service interface
   – then passes the security services handlers one after the another until it
     invokes the implementation of that security service
   – after service execution, the response may also tunnel through some
     other security services handlers before it gets to client side
   – a handler may communicate with a corresponding Grid Monitoring and
     Managing Services (GMMS) during the procedure & send monitoring
     information to that GMMS according to Web Services Level Agreement
     (WSLA)

• Handler modules develop as plug-ins for OGSA container
   – handlers can be inserted or removed from the container at any moment.
   – plug-in mechanism brings high flexibility
       • we can customize needed handlers in the container to fit different scenarios
       • we can specify different handlers in service deployment stage in order to do
         different monitoring functions
  22 November 2005            Security & Trust for the Grid                    57
                    Extension of GSI
• The Grid Security Infrastructure (GSI) does not attempt to
   – discover middleboxes; and
   – negotiate security with them
• As a result
   – security gaps could surface
        • particularly in cases where some grid resources and nodes exist in a
          local network behind a firewall
   – adaptability of GSI becomes limited making it hard to port it to
     lightweight devices with limited capabilities

• We extend the GSI to enable it to adapt environments with
  varying conditions that incorporates greater flexibility,
  adaptability, and customizability.
 22 November 2005            Security & Trust for the Grid                   58
       Formal Security Evaluation
• Independent (third party) attestation of a developer‟s
  security claims against a defined security evaluation
  criteria.
• Evaluations result in independent measure of
  assurance, therefore build confidence in security.
• Secures development process and yields better
  product.
• Comprehensive security solutions cannot be
  evaluated by simple examination!


22 November 2005    Security & Trust for the Grid     59
CC for Grid Security Architecture
• Both CC and Computational Grids have emerged by the
  late 1990s.
• However, the Grid community lacks experience in the
  exercise of CC!
• Perhaps, because security features were overlooked in
  the early Grid endeavors …
• The growing size and profile of Grid oblige its designers
  to incorporate adequate security solutions.
• The assessment of these solutions require excellent
  evaluation criteria.
• CC is the best available criteria for these assessments.
22 November 2005     Security & Trust for the Grid        60
      CC Evaluation – Case Study
• We have prepared a formal Protection Profile (PP)
  – Target of Evaluation (TOE) : Health Grid
  – Common Criteria (CC) version 2.1
  – Evaluation Assurance Level (EAL) = 4
       • EAL4
  – minimum Strength of Function (SOF) = HIGH
       • SOF-high

    Naqvi S., Riguidel M., „Evaluation of Grid Security Solutions using Common
    Criteria‟, In the Proceedings of the Computing in High Energy Physics 2004
    (CHEP‟04), Interlaken - Switzerland, September 27 - October 01, 2004. pp
    854-857 (ISBN 9290832452)

  22 November 2005           Security & Trust for the Grid                   61
              G3S
Grid Security Services Simulator
                          G3S
• G3S : Grid Security Services Simulator
    – Open source code
    – Developed in Java
    – Provides simulations features for the Grid
      security functionalities
    – Some pervasive features are also included
    – Can be integrated on the top of GridSim


22 November 2005   Security & Trust for the Grid   63
                                       GridSim




                                        Core




DocumentExchange      SecurityPolicy               TrustManagement   Attack




   22 November 2005           Security & Trust for the Grid               64
22 November 2005   Security & Trust for the Grid   65
Conclusions
 Grid Security – Medieval Period
• Security threats were overlooked in the desire to
  implement a high performance distributed computational
  system.
• Grid community was composed of „Good Guys‟ :
  Academics & Public Researchers.
• This community was interested to share resources on
  the grid, and had no intention of harming the resource
  owners or fellow users.
• Grid users were the „known‟ and „trusted‟ persons of the
  resource providers.
• Applications running over these Grids and data being
  exchanged were not „interesting‟ for the attackers!
22 November 2005     Security & Trust for the Grid       67
 Grid Security – Medieval Period
• The pioneer Grid security solution – GSI – was a
  good start.
• GSI was meant to provide „basic‟ security.
• In-depth security was perhaps not required for the
  community composed of „good guys‟
• Other security initiatives include:
  SHARP: Secure Highly Available Resource Peering
  Sandbox, …
• BUT all these initiatives were based on the security
  solutions of the existing distributed applications with
  some modifications.

22 November 2005      Security & Trust for the Grid         68
Today: There is SOME Confusion!
• We all agree that:
   Grid is DIFFERENT from other Distributed Technologies
   (like CORBA, Clusters, Pervasive Computing, …)

• Then the Grid Security should also be different from the
  other existing security technologies ???

• We say that:
   Grid Security should be based on CURRENT standards

• But it should not be implied that
   Grid Security should be based on EXISTING solutions!
22 November 2005       Security & Trust for the Grid         69
  There is SOMETHING missing
• For the Grid Security:
    – We are not following the standard security practices
      (requirements analysis, simulations, evaluations, …)
    – It seems that we are only looking for quick solutions.
    – We are interested to develop these solutions but are reluctant to
      do research on new security paradigms.
    – This „Crash Approach‟ or the „State of Emergency‟ may be
      acceptable for sometime BUT we can not envision a good future
      based on the current attitude.


• It may be the time for the RENAISSANCE of the
  Grid Security approach!
22 November 2005          Security & Trust for the Grid               70

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:41
posted:2/19/2010
language:English
pages:70
Description: grid computing