Presentation is loading. Please wait.

Presentation is loading. Please wait.

Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 C O R P O R A T E T E C H N O L.

Similar presentations


Presentation on theme: "Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 C O R P O R A T E T E C H N O L."— Presentation transcript:

1 Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Security Protocols: Analysis and Verification Problems in Security Protocol Design Colloquium on Risk and Security of the Internet and Systems CRiSIS 2005, October 2005 Jorge.Cuellar@siemens.com

2 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Questions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Where are the issues? Complexity of system? Language? Modeling? Abstraction layer? Compositionality? How much of the security landscape can be addressed today by FM?

3 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? Increasing, but still minor

4 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Quite a bit: we understand better the protocol, the assumptions, the possible extensions, variants of the protocol

5 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Yes, still very many

6 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Where are the issues? Complexity of system? Yes

7 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Where are the issues? Complexity of system? Language? Modeling? Yes

8 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Where are the issues? Complexity of system? Language? Modeling? Abstraction layer? Yes

9 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Where are the issues? Complexity of system? Language? Modeling? Abstraction layer? Compositionality? Yes

10 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions How far is verification of security protocols and systems? Impact? What do we learn from verification? Are there protocols that we understand, but we do not know how to tackle? Where are the issues? Complexity of system? Language? Modeling? Abstraction layer? Compositionality? How much of the security landscape can be addressed today by FM? Not too much

11 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Three Classes of Security Problems Protocols that are able to model and to verify See AVISPA (Automated Verification of Internet Security Protocols and Applications). FET Open. IST-2001-39252 snd BWW Project 02.0431, Jan 1, 2003 – June 30, 2005 http://www.avispa-project.org Protocols that we understand, but their verification is still difficult Problems for which there is still no well-defined solution

12 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Context: Standardisation Committees Layers 802.11 GSM OMA IEEE IP UDP TCP HTTP Envelope (MIME ) html WS-I xml Namespaces + Information Set SOAP xml Signature WS-Sec SAML xml Encryption WSDL xml Schema UDDI Register Search Subscribe 3GPP IETF W3C Oasis ID-FF 1.1 LECP LAP UMTS They still make many design errors

13 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Context: Security Today Mostly Network Security 2 trusted devices communicate over not trusted networks Who is this user? server? Trust: Does he keep his keys secure? What is he allowed to do? Is this user known to a T3P? Is the trusted 3rd party behaving correctly? Security Goals: non-repudiation, secrecy, integrity Security Mechanisms: encryption, key agreement

14 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security The End-to-End Paradigm Protocols we can prove 1

15 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security The Philosopher-translator-secretary Architecture Philosophers (L4) discuss using pure ontology R/W (L3), Translators (L2), Secretaries (L1), Intermediaries Philosopher sends “theories” to peer. Each protocol is independent of the other ones. The Translators can switch from German to say, Finnish. Secretaries can switch from fax to e-mail or telephone without even informing the other layers. Each process may add some information intended only for its peer. Based on A. S. Tanenbaum Layers R/W Translator Secretary Translator Secretary R/W “Translator” Secretary UrduFrench German Courier Fax Courier Secretary Philosopher Pure ontologyPure Ontology

16 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security The Philosopher-translator-secretary Architecture May study the layers almost independently Based on A. S. Tanenbaum Layers R/W Translator Secretary Translator Secretary R/W “Translator” Secretary UrduFrench German Courier Fax Courier Secretary Philosopher Pure ontologyPure Ontology

17 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Life is OK: IETF View Access Point or Gateway DNS,PKI tcp / udp ip Ethernet DNS,PKI tcp / udp ip Ethernet Host Middleware Transport Layer Network Layer Data Link Layer Physical Layer WLAN-Wep IPsec-IKE TLS OCSP SET Application Layers

18 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Where life is OK Areas where we can prove correctness (AVISPA Project) Infrastructure (DHCP, DNS, BGP, stime) Network Access (WLAN, pana) Mobility (Mobile IP, UMTS-AKA, seamoby) VoIP, messaging, presence (SIP, ITU-T H530, impp, simple) Internet Security (IKE (IPsec Key agreement), TLS, Kerberos, EAP, OTP, Sacred, ssh, telnet,...) Privacy (Geopriv) AAA (DIAMETER), Identity Management, Single Sign On (Liberty Alliance) Security for QoS, etc. (RSVP, NSIS) Broadcast/Multicast Authentication (TESLA) E-Commerce (Payment) AVISPA covers most of the standard IETF Security Protocols (plus some current ones, under discussion)

19 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Reasoning about Protocols — standard Model: D-Y Intruder D-Y Intruder may: Intercept / emit messages Decrypt / encrypt with known key (Black-box perfect crypto) Split / form messages Use public information Generate fresh data Assume: perfect cryptography channel: data + Control msgs trustworthy device trustworthy device {A, n A } KeyB {A, n I } KeyB A, n I, KeyA, KeyB Intruder Knowledge

20 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Example: NS Public-Key (1978) B believes he is speaking with A! {A, n A } KeyB { n A, n B } KeyA { n B } KeyB {A, n A } KeyI { n A, n B } KeyA { n B } KeyI { n B } KeyB { A, n A } KeyB { n A, n B } KeyA

21 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security The AVISPA Specification Language HLPSL Relatively high degree of abrstaction Rather expressive: Crypto-Operatorion: Encryption, Signature, Hashes, Nonces Algebraic Properties (e.g. exp und xor) Control flow: branching on conditions and loops Intruder knowledge explicitely definable Modularity: Composition of Roles in local environments Security goals: Secrecy, weak and strong authentication, temporal logic properties Reference semantic very close to TLA May be interpreted as a set of rewrite rules (search backwards with unification) Type system with complex Data types Easy to learn and use (  Programming Language)

22 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Basic Roles role Basic_Role (…) def= owns {θ: Θ} local { ε} init Init accepts Accept transition event1  action1 event2  action2 … end role role Alice (A, B: agent, Ka, Kb: public_key, SND, RCV: channel (dy)) played_by A def= local State:nat, Na:text (fresh), Nb:text init State = 0 knowledge(A) = {inv(Ka), Ka, Kb, ki} transition 1. State =0 /\ RCV(start) =|> State'=2 /\ SND({Na'.A}Kb) /\ witness(A,B,na,Na') 2. State =2 /\ RCV({Na.Nb'}Ka) =|> State'=4 /\ SND({Nb'}Kb) /\ request(A,B,nb,Nb') /\ secret(Na,B) end role General PatternInitiator Role in NSPK

23 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Composed Roles: Parallel Composition role Par_Role (…) def= owns {θ:Θ} local { ε} init Init accepts Accept composition A  B end role PatternExample role Kerberos (..) composition Client /\ Authn_Server /\ TGS /\ Server end role

24 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Composed Roles: Sequential Composition role Seq_Role (…) def= owns {θ:Θ} local { ε} init Init accepts Accept A ; B end role General PatternExample role Alice (..) establish_TLS_Tunnel(server_ authn_only); present_credentials; main_protocol(request, response) end role

25 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security New Paradigms Problems/Protocols we think we understand but we can’t solve or prove 2

26 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Sources of new Complexity 1.Complex Inter-layer Relation 2.Groups Example: Broadcast Streaming 3.Mission Impossible: Better-than-nothing security 4.Dynamic and continuously evolving systems Service-oriented computing Web Services New Problem Areas

27 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security IETF provides secure channels (IPsec, TLS,..), OMA uses them The high-level spec is built upon “secure channel assumption” If a device is not trusted (or the user), how to make keys available only to „application A“ and not to untrusted layers? How to prove that I am „application A“? Identities user name, IP address, MAC, TCP port,... What is “A”, “Alice”, “ID_A”? Network Layers and dependencies Application A Untrusted Peer Untrusted

28 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Inter-protocol, Inter-Layer Dependencies Example: SIP User interface (buddy list, etc.) SIPICERTP/RTCP Codecs Audio devices DHT (Chord) On startup Discover User location Multicast REGPeer found/ Detect NAT REG REG, INVITE, MESSAGE Signup, Find buddies Join Find Leave On reset Sign-out, transfer IM, call

29 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Authorization Framework Basic Rule set Extended Rule set Application Domain and Use Cases SIP/SIMPLERADIUS/Diameter DHCP Location based Services, Presence and IM Emergency Calls and Location based Call Routing Location based Network Access Authorization, Taxation and Billing Common Policy Using Protocols Location Configuratio n Conferencing Application Domain and Use Cases DHCP Option Geopriv Policy Presence Policy PIDF-LO Conference Policy Inter-Layer dependencies: Embedded Protocols: Example: Geopriv

30 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Broadcast Streaming The final game of the world championship Millions of users, worldwide But not all users have subscribed to this one transmission Uni-directional Channels Change of Keys each 20 Secs Broadcast of Keys?

31 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Better-than-nothing, less than perfect security Conditional Security over the air “safer” routes Many types of DoS attacks flooding, bombing, starving, disrupting Layered Properties: if attacker... then..., if attacker... then...

32 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security One WS View (Open Grid) HTTP https IIOP CSIv2 JMS (MQ)... Protocol layer security AttributeServiceAuthnServiceAuthzServiceAuditService... Security services (TBD) AppServer security Platform (OS) security Application security (on top of app server) Exploiters XML security standards XML Signature XML Encryption XACMLXKMS Assertion Language... Message Security ds: Signature xenc: EncryptedData SecurityToken... Policy layer WS-Policy WS-TrustWS-Privacy WS-FederationWS-SecureConversationWS-Authorization Federation layer Web services standards WSDLSOAPWS*L... WS-Routing Platform resource security NTLinuxAIXSolaris... Layers

33 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Another WS Security View proposed SOAP Foundation WS-Security WS-Privacy WS-SecureConversation WS-Federation WS-Authorization In progress promised SAML Liberty Alliance WS-Trust WS-Policy-* XACML standardized XrML Layers

34 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Web Services: One Possible Scenario Proxy Application Main Web Server Retailer WS Use Supplier User XKMS Server SAML Authorities ? Security must be a function of the business model

35 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Web Services: One “Architechture” WebServ Users Portal (Presentation) WServers DBs Single-Sign On, Trust Federation Authn, Authz, Account, Audit Delegation Business Process vs. Security Policies Challenges:

36 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Security Services and Composition How to model a generic Identity Provider, a secure mail provider, a secure time-stamp server? How to reason about secure services composition?

37 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Web Services: Orchestration and Management Some Protocols BPEL BTP (OASIS) ebXML BP (OASIS/CEFACT) WSBPEL (OASIS) WS-Chor (W3C) WS-CAF (OASIS) ASAP (OASIS) WSDM (OASIS) WS-RF (OASIS) WS-Notification (OASIS) Private specs for Transactions Choreography Notification Eventing Management Higher-level security services  more application-layer access via gateways, proxies, … Difficult semantics of orchestration languages and of business models

38 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security How to cope with the complexity? Many types of channels, weaker than Dolev-Yao: Over the air Authentic Channels Confidential Channels Proof Channels (Non-Repudiation of reception / send) Abstraction Layers One sub-protocol provides a secure channel, the other one uses it The channel mutation problem Exercise: SSO over http-s: A ― B c c A ――> B PW B A IdP

39 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Protocols we can not design 3

40 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Where we do have Problems 1.Configuration, Operation 2.Global Routing and keying 3.Policies for all purposes 4.E2E QoS and Signaling 5.Local routing and keying 6.Homeland Security 7.Trustworthiness Current (+Future) Problem Areas New Problem Areas

41 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Deployment, Configuration, Operation, User Interface Encryption and authentication algo are ±ok Activating these mechanisms Key management (PKI,...): weak Secure configurations Epidemics, cascades, flexible policies User interface problem Users don’t know what certificates are identities aren’t checked NASA.COM or NASA.GOV? MICROSOFT.COM or MICROSОFT.COM? (Cyrillic “O”)

42 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Deployment, Configuration, Operation, User Interface Encryption and authentication algo are ±ok Activating these mechanisms Key management (PKI,...): weak Keys are a single point of failure, Key revocation Secure configurations Epidemics, cascades, flexible policies A worm may infect all vulnerable servers in Internet in less than a minute User interface problem Users don’t know what certificates are, certificates’ real-world identities aren’t checked Who is Dow, Jones? Who owns www.wsj.com? NASA.COM or NASA.GOV? MICROSOFT.COM or MICROSОFT.COM? (Cyrillic “O”)

43 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Global Routing, Keying Internet as a Global village? in a village, you know your neighbours BGP-4 Secure Diffusion of Routing Information

44 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Global Routing: Address-space ownership Example: Bombing HoA In MIPv6 the MN has a default address, to which data will be sent when its current location is unknown. Attacker claims to have a HoA in the target network. It starts downloading a data stream and either sends a request to delete the binding cache entry or allows it to expire. This redirects the data stream to the false HoA. Target can do nothing to prevent the attack. Attacker needs to find a CN that is willing to send data streams to unauthenticated recipients. Many popular web sites provide such streams

45 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Policies for everything DOS, security attacks  permissions-based communications only allow modest rates without asking effectively, back to circuit-switched Forcing homogeneity on users is useless Everyone has his own preferences User control of communications from anywhere, anytime, any media to where appropriate, my time, my media fix spam keep cell phone from ringing in the concert Meta-policies Policy refinement (logical implication) Modularity, Conjunction, Negation, Distribution, Resolution

46 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security E2E Signaling NAT/FW QoS

47 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Local Routing and Keying Myriad of Wireless small devices embedded in physical objects and other components S mall and invisible, low-cost, Ad-hoc Routing Wireless communication Radio transmitter + receiver, Atom-clocks, etc. in millimetres wearables media players sensors cameras MEMS (Micro-electro-mechanical systems) Sensor Networks Active Badges and Tags (RFID) Hierarchical key management? (Personal CAs) Trust? Privacy?

48 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Inter-protocol, Inter-Layer Dependencies Create Secure Channel at one layer Use it to generate a secure channel at a different layer GBA-U On the other hand: decoupling Middleware Application

49 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Homeland Security Security for Critical Infrastructures Lots of technologies involved New and more expensive Vulnerabilities Big events (Olympia), Large Projects (E-health card) SCADA: 24/7 availability Many of the usual security mechanisms do not apply Password management Patches Protocols, policies for critical situations Cascade Control Congestion control in Emergency

50 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Encrypted Content, Rights Object Terminal ID, Keys Secure Container DRM Agent Renders the Content Operating System HW drivers UserTerminalContent Provider Manufacturer Trust modelling challenge: Example: DRM {C} CEK {R, CEK} DK

51 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Encrypted Content, Rights Object Viruses Untrusted SW Terminal ID, Keys Secure Container Trojan Horses UserTerminalContent Provider Manufacturer The Problem DRM Agent Renders the Content Operating System HW drivers How can T prove to CP that he will use C only according to R? Proof

52 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Trustworthiness Trustworthiness: Measuring and proving Trusted Computing How can one machine prove to another one (say both in a home environment) that one will respect the policies installed in the other? Reputation and Risk Management Rights Object Rendering Agent Operating System Drivers Trojans? Proof

53 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions

54 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Security Future Complex trust assumptions and guarantees Policies everywhere, Ownership Finer granularity of rights Devices: many, embedded, ubiquitous Which keys are on the device? Stolen Devices Untrusted Users, Tamper Resistance May I trust my own device? Shared devices? Viruses and Trojan Horses May I trust someone else’s device/platform/service? Composition Online Composing Security Services Policies everywhere, Ownership

55 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Security Future Security Goals: non-repudiation, secrecy, integrity, qualified signatures with user interaction, service exposure limits Security Mechanisms: encryption, key agreement, redundancy, trust management, online verification of the integrity of services or platforms, self-healing and immunity techniques, resilience

56 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions, again Specification Languages and Logics for emerging security standards Too specific, lack abstraction level for business Stakeholder should define sec goals at orchestration or business flow level And attacker model Automatically derive the low-level security mechanisms (or proof) Today services and applications are considered secure because they use security mechanisms and protocols But this is dangerous Need a “logic” to reason about the security provided by resources and their interaction Using special channels Calling special servers (for attestation, signed timestamps, etc.). Decomposing and enforcing Global security policies

57 © Siemens AG, CT IC 3, J. Cuellar Oct 2005 C O R P O R A T E T E C H N O L O G Y Information & Communications Security Conclusions, again New security topics: Service-oriented computing dynamic and continuously evolving. Integration of trusted platforms Self-healing and immunity techniques Exchange of emergency information, lawful interception, filtering for critical infrastructure security


Download ppt "Automated Validation of Internet Security Protocols and Applications Shared cost RTD (FET open) project IST-2001-39252 C O R P O R A T E T E C H N O L."

Similar presentations


Ads by Google