A Reverse Proxy for Voip Or How to Improve Security in a Toip Network

Total Page:16

File Type:pdf, Size:1020Kb

A Reverse Proxy for Voip Or How to Improve Security in a Toip Network DEGREE PROJECT IN ELECTRICAL ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2016 A reverse proxy for VoIP Or how to improve security in a ToIP network GUILLAUME DHAINAUT KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING KTH Royal Institute of Technology Master’s Programme in Network Services and Systems - ANSSI Guillaume Dhainaut 921006-5950 [email protected] A reverse proxy for VoIP Or how to improve security in a ToIP network Master’s Thesis Stockholm, February 24, 2016 Supervisors Pierre Lorinquer ANSSI Fabien Allard ANSSI Examiner Panagiotis Papadimitratos ([email protected]) KTH Abstract The need for security is crucial in Telephony over IP (ToIP). Secure protocols have been designed as well as specific devices to fulfill that need. This master thesis examines one of such devices called Session Border Controller (SBC), which can be compared to reverse proxies for ToIP. The idea is to apply message filters to increase security. This thesis presents the reasons of SBC existence, based on the security weaknesses a ToIP network can show. These reasons are then used to establish a list of features which can be expected from a SBC and discuss its ideal placement in a ToIP network architecture. A test methodology for SBCs is established and used on the free software Kamailio as an illustration. Following this test, improvements of this software, regarding threats prevention and attacks detection, are presented and implemented. Sammanfattning Behovet av säkerhet är av avgörande betydelse i telefoni över IP (ToIP). Säkerhet- sprotokoll har utformats samt särskilda enheter för att uppfylla detta behov. Detta examensarbete undersöker en av sådana enheter som kallas Session Border Controller (SBC), vilket kan jämföras med omvända proxyservrar för ToIP. Tanken är att tillämpa meddelandefilter för att öka säkerheten. Denna avhandling presenterar orsakerna till SBC existens, baserat på de säkerhets svagheter en ToIP nätverk kan visa. Dessa skäl används sedan för att upprätta en förteck- ning över egenskaper som kan förväntas av en SBC och diskutera dess ideal placering i en ToIP nätverksarkitektur . En testmetodik för SBC är etablerad och används på fri programvara Kamailio som en illustration. Efter detta test, förbättringar av denna pro- gramvara, om hot förebyggande och attacker upptäcka, presenteras och genomförs. i Acknowledgements This research was supported by ANSSI (French Network and Information Security Agency) in Paris. They offered me helps and materials. I owe my gratitude to Pierre Loriquer and Fabien Allard which were my ANSSI supervisors and helped me throughout this thesis by giving me advice and idea. I would also like to thank Colin Chaigneau and Valentin Houchouas, my colleagues at ANSSI, for their helps in areas of which they were experts. I am thankful to Panagiotis Papadimitratos, my supervisor at KTH, for his helpful advice about the report. Finally I thank Alice Tourtier for her help and support. ii Contents 1 Introduction1 1.1 Goal of the thesis................................1 1.2 Contribution...................................2 1.3 Outline......................................2 2 VoIP Technologies3 2.1 SIP........................................4 2.1.1 Messages.................................4 2.1.2 Elements of a SIP call establishment.................6 2.1.3 Exchange examples...........................8 2.1.4 Security Mechanisms..........................9 2.2 Media session protocols............................. 11 2.2.1 Codecs.................................. 11 2.2.2 RTP................................... 12 2.2.3 SRTP.................................. 13 2.2.4 RTCP.................................. 14 2.2.5 SDP................................... 15 2.3 Other protocols................................. 16 2.3.1 VoIP protocols............................. 16 2.3.2 Service protocols............................ 17 2.4 Unified Communications............................ 17 3 Security on a ToIP infrastructure 19 3.1 Security issues in ToIP............................. 19 3.1.1 Risks................................... 19 3.1.2 Common ToIP attacks......................... 21 3.1.3 How to make secure ToIP....................... 23 3.1.4 Limits.................................. 25 3.2 Session Border Controller........................... 27 3.2.1 Principle................................. 27 3.2.2 Differences with existing devices.................... 29 4 SBC features 30 4.1 Internetworking................................. 30 4.2 Media...................................... 30 4.3 QoS....................................... 31 4.4 Security..................................... 32 4.4.1 Upstream protection.......................... 32 4.4.2 Common attack protection....................... 34 4.4.3 Downstream protection......................... 36 5 SBC Architecture integration 39 5.1 At the border of ToIP architecture...................... 39 5.1.1 Presentation............................... 39 5.1.2 Limits.................................. 40 5.2 At the Center of ToIP architecture...................... 40 iii 5.2.1 Presentation............................... 40 5.2.2 Limits.................................. 40 5.3 Combination................................... 41 6 SBC Security Test 42 6.1 Methodology.................................. 42 6.1.1 Test environment............................ 42 6.1.2 Features announced........................... 42 6.1.3 Fuzzing................................. 43 6.1.4 Dos/Flood................................ 43 6.1.5 TLS quality............................... 44 6.1.6 Common SIP attacks.......................... 44 6.2 Test of Kamailio................................ 45 6.2.1 Test environment............................ 45 6.2.2 Results.................................. 47 6.2.3 Conclusion................................ 51 7 Improvements 52 7.1 Permissions module............................... 52 7.1.1 Logic................................... 52 7.1.2 Implementation............................. 53 7.2 CDR analysis.................................. 53 7.2.1 Logic................................... 53 7.2.2 Implementation............................. 56 7.2.3 Tests................................... 56 8 Conclusion and future work 60 8.1 Accomplished work............................... 60 8.2 SBC conception................................. 60 8.3 Future work................................... 61 A Loop amplification Attack 66 B Kamailio configuration files 67 C Asterisk configuration files 70 iv List of Figures 1 ITU-T protocol set...............................3 2 VoIP IETF protocol set............................4 3 Example of a SIP INVITE message......................5 4 SIP Registration process............................8 5 SIP Call process.................................9 6 SIP Digest authentication example...................... 10 7 RTP header as defined in RFC 3550 [1].................... 13 8 Example of a SDP description......................... 15 9 Example of DoS attack with INVITE messages............... 22 10 Security measures at the network level.................... 25 11 Example of SBC placement.......................... 28 12 Use of a B2BUA to transcode audio flow................... 28 13 SBC action to allow high frequency registration............... 33 14 Internal architecture with a SBC at the border of the ToIP network.... 39 15 VoIP flows with a SBC at the center..................... 40 16 Internal architecture with two SBCs at the border and at the center of the ToIP network.................................. 41 17 Test environment of Kamailio......................... 47 18 CPU and RAM usages versus message intensity during DoS attacks.... 49 19 Learning period in time............................ 55 20 Example of a user profile............................ 57 21 Call hour distribution for a user........................ 58 22 Receiver Operating Characteristic for the call classifier........... 59 23 REGISTER messages of a loop amplification attack............. 66 24 Example of the flow of a SIP amplification attack from RFC 5393 [2]... 66 v List of Tables 1 Main SIP request methods...........................5 2 Main SIP response codes............................5 3 Main audio codecs............................... 12 4 Codecs understood by some SIP systems................... 31 5 Overview of the security features....................... 43 6 Security features implemented in Kamailio.................. 48 7 Kamailio DoS results.............................. 49 8 FPR and TPR results............................. 58 vi Abbreviations and Acronyms ANSSI French Network and Information Security Agency B2BUA Back-to-Back User Agent CA Certificate Authority CAC Call Admission Control CDR Call Detail Record CoS Class of Service CPE Customer Premises Equipment CPU Central Processing Unit CVE Common Vulnerabilities and Exposures DHCP Dynamic Host Configuration Protocol DNS Domain Name System DoS Denial of Service DDoS Distributed DoS DTLS Datagram Transport Layer Security DTMF Dual-Tone Multi-Frequency ERP Enterprise Resource Planning FPR False Positive Ratio FTP File Transfert Protocol HTTP Hypertext Transfer Protocol HTTPS HTTP Secure IAX Inter-Asterisk eXchange ICE Interactive Connectivity Establishment IETF Internet Engineering Task Force IP Internet Protocol IPBX Internet PBX IPsec Internet Protocol Security ISDN Integrated Services Digital Network ISUP Integrated Services Digital Network User Part ITU International Telecommunication Union ITU-T ITU Telecommunication Standardization
Recommended publications
  • Webrtc and XMPP
    webRTC and XMPP Philipp Hancke, XMPP Summit 2013 What is this webRTC thing … …and why should XMPP developers care? . I assume you know what XMPP is… . … you might have heard of Jingle . the XMPP framework for establishing P2P sessions . used for VoIP, filesharing, … . … you might have also heard about this webRTC thing . doing VoIP in the browser . without plugins . „no more flash“ . Do you want to know how it relates to XMPP ? Philipp Hancke © ESTOS GmbH 2013 2 What is webRTC? . P2P sessions between browsers . no servers involved in media transfer . using open standards . Javascript API in the browser . also an BSD-licensed C++ library from Google . Want to know more? . Listen to the evangelists! . Justin Uberti http://www.youtube.com/watch?v=E8C8ouiXHHk . Jose de Castro http://vimeo.com/52510068 . Cullen Jennings http://vimeo.com/cullenfluffyjennings/rtcwebexplained Philipp Hancke © ESTOS GmbH 2013 3 Initiating P2P sessions . initiate a P2P session between two browsers . negotiate media codecs, NAT traversal, etc . media is sent P2P . you need a session initiation protocol . SIP? . JSEP? . H.323? . Jingle! . webRTC does not mandate a signalling protocol . WG decision Philipp Hancke © ESTOS GmbH 2013 4 Call Flow - JSEP Philipp Hancke © ESTOS GmbH 2013 5 Jingle . You can use Jingle as signalling protocol . together with BOSH or XMPP over websockets in the browser . Demo later . But… . webRTC uses the Session Description Protocol as an API . Jingle does not use SDP . You need a mapping SDP -> Jingle -> SDP . Complicated, but doable . Topic for breakout Philipp Hancke © ESTOS GmbH 2013 6 Call Flow - Jingle Philipp Hancke © ESTOS GmbH 2013 7 webRTC-Jingle usecases .
    [Show full text]
  • Cisco SCA BB Protocol Reference Guide
    Cisco Service Control Application for Broadband Protocol Reference Guide Protocol Pack #60 August 02, 2018 Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
    [Show full text]
  • Skype Voip Service- Architecture and Comparison Hao Wang Institute of Communication Networks and Computer Engineering University of Stuttgart Mentor: Dr.-Ing
    INFOTECH Seminar Advanced Communication Services (ACS), 2005 Skype VoIP service- architecture and comparison Hao Wang Institute of Communication Networks and Computer Engineering University of Stuttgart Mentor: Dr.-Ing. S. Rupp ABSTRACT Skype is a peer-to-peer (P2P) overlay network for VoIP and other applications, developed by KaZaa in 2003. Skype can traverse NAT and firewall more efficiently than traditional VoIP networks and it offers better voice quality. To find and locate users, Skype uses “supernodes” that are running on peer machines. In contrast, traditional systems use fixed central servers. Also Skype uses encrypted media channel to protect the dada. The main contribution of this article is illustrating the architecture and components of Skype networks and basically analyzing key Skype functions such as login, NAT and firewall traversal. Furthermore, it contains comparisons of Skype networks with VoIP networks regarding different scenarios. On that basis it reveals some reasons why Skype has much better performance than previous VoIP products. Keywords Voice over IP (VoIP), Skype, Peer-to-peer (p2p), Super Node (SN) 1. Introduction It is expected that real-time person-to-person communication, like IP telephony (VoIP), instant messaging, voice, video and data collaboration will be the next big wave of Internet usage. VoIP refers to technology that enables routing of voice conversations over the Internet or any other IP network. Another technology is peer-to-peer, which is used for sharing content like audio, video, data or anything in digital format. Skype is a combination of these two technologies. It has much better performance by making use of advantages of both technologies.
    [Show full text]
  • Devicelock® DLP 8.3 User Manual
    DeviceLock® DLP 8.3 User Manual © 1996-2020 DeviceLock, Inc. All Rights Reserved. Information in this document is subject to change without notice. No part of this document may be reproduced or transmitted in any form or by any means for any purpose other than the purchaser’s personal use without the prior written permission of DeviceLock, Inc. Trademarks DeviceLock and the DeviceLock logo are registered trademarks of DeviceLock, Inc. All other product names, service marks, and trademarks mentioned herein are trademarks of their respective owners. DeviceLock DLP - User Manual Software version: 8.3 Updated: March 2020 Contents About This Manual . .8 Conventions . 8 DeviceLock Overview . .9 General Information . 9 Managed Access Control . 13 DeviceLock Service for Mac . 17 DeviceLock Content Security Server . 18 How Search Server Works . 18 ContentLock and NetworkLock . 20 ContentLock and NetworkLock Licensing . 24 Basic Security Rules . 25 Installing DeviceLock . .26 System Requirements . 26 Deploying DeviceLock Service for Windows . 30 Interactive Installation . 30 Unattended Installation . 35 Installation via Microsoft Systems Management Server . 36 Installation via DeviceLock Management Console . 36 Installation via DeviceLock Enterprise Manager . 37 Installation via Group Policy . 38 Installation via DeviceLock Enterprise Server . 44 Deploying DeviceLock Service for Mac . 45 Interactive Installation . 45 Command Line Utility . 47 Unattended Installation . 48 Installing Management Consoles . 49 Installing DeviceLock Enterprise Server . 52 Installation Steps . 52 Installing and Accessing DeviceLock WebConsole . 65 Prepare for Installation . 65 Install the DeviceLock WebConsole . 66 Access the DeviceLock WebConsole . 67 Installing DeviceLock Content Security Server . 68 Prepare to Install . 68 Start Installation . 70 Perform Configuration and Complete Installation . 71 DeviceLock Consoles and Tools .
    [Show full text]
  • Insight Into the Gtalk Protocol
    1 Insight into the Gtalk Protocol Riyad Alshammari and A. Nur Zincir-Heywood Dalhousie University, Faculty of Computer Science Halifax NS B3H 1W5, Canada (riyad,zincir)@cs.dal.ca Abstract Google talk (Gtalk) is an instant messeger and voice over IP client developed by Google in 2005. Gtalk can work across firewalls and has very good voice quality. It encrypts calls end-to-end, and stores user information in a centralized fashion. This paper analyzes fundamental Gtalk functions such as login, firewall traversal, and call establishment under different network scenarios. The analysis is performed by both active and passive measurement techniques to understand the Gtalk network traffic. Based on our analysis, we devised algorithms for login and call establishment processes as well as data flow models. I. INTRODUCTION Voice over IP (VoIP) is becoming a major communication service for enterprises and individuals since the cost of VoIP calls is low and the voice quality is getting better. To date, there are many VoIP products that are able to provide high call quality such as Skype [1], Google Talk (Gtalk) [2], Microsoft Messenger (MSN) [3], and Yahoo! Messenger (YMSG) [4]. However, few information has been documented about protocol design used by these VoIP clients since the protocols are not standardized, many of them are proprietary, and the creators of these softwares want to keep their information confidential and protect their protocol design form competitors. In this paper, we have generated and captured network traffic in order to determine the broad characteristics of one of the most recent and fast growing VoIP applications, Google Talk.
    [Show full text]
  • Copyrighted Material
    Stichwortverzeichnis A B Abstreitbarkeit 167 Bequemlichkeit 30 Adblocker 96 Bitcoin 110 – Adblock Plus 96 Blackberry 215 – Disconnect 96 Bookmarks siehe Favoriten – Ghostery 96 Browser 68, 75 – Privacy Badger 96 – Add-on 87, 90 – uBlock 97 – Apple Safari 77 Add-on – Cache 88 – Browser 87, 90 – Chromium 78 – E-Mail-Client 126 – Chronik 87 – Enigmail siehe Enigmail – Fingerprinting 85, 98 – GpgOL 137 – Google Chrome 77 – Mailvelope 130, 132 – HTML-Engine 80 – Thunderbird 139 – Hygiene 88 Adium 170 – Iceweasel 78 Advanced Programming Interface (API) 90, – Inkognito-Modus 86 182 – integrierte Suche 84 Android – Internet Explorer 77 – Android Privacy Guard (App) 156 – Konqueror 78 – K9 Mail (E-Mail-Client) 156 – Microsoft Edge 92 – OpenKeychain (App) 156 – Midori 78 – PGP 156 – Mosaic 68 – R2Mail2 (E-Mail-Client) 158 – Mozilla Firefox 68, 76 – S/MIME 156 – Netscape Navigator 68 Anonymität 206 COPYRIGHTED– Opera 77MATERIAL AOL Instant Messenger (AIM) 164 – Plug-in 87 Apple Mail – Prole (Identitäten) 87 – PGP 145 – Synchronisation von Einstellungen – S/MIME 155 86 Authentizierung 167, 169, 176, 179 – Web (Epiphany) 78 – Adium 172 Buffer Overow 82 – Multifaktor- 201 Bugs 82 – Pidgin 169 Bundesamt für Sicherheit in der Informations- Authentizität 29, 54, 56 technik (BSI) 215 233 Stichwortverzeichnis C – E-Mail-Adresse 119 Caesar-Chiffre 36 – Header 121 Certicate Authority siehe Zertizierungsstelle – Provider 129, 131, 139 Chain of Trust siehe Web of Trust – Server 122 Chaos Computer Club (CCC) 133 Eingangsverschüsselung 125 Chat 161 Electronic
    [Show full text]
  • Google Talk: Is It Ready for the Enterprise?
    Research Publication Date: 16 April 2009 ID Number: G00166834 Google Talk: Is It Ready for the Enterprise? David Mario Smith, James Lundy This report discusses the Google Talk instant messaging product and its suitability for enterprises. This is important for companies which are looking at alternatives to IBM and Microsoft for messaging and collaboration. Key Findings • Google Talk IM is based on the Extensible Messaging and Presence Protocol (XMPP) and Jingle protocols. • To get enterprise-level support for Google Talk, companies have to purchase the full Google Apps Premier Edition (GAPE) suite. • Enterprise users are already using the Google Talk and Gmail free services. Recommendations • Enterprises making collaboration decisions should include the Google Apps portfolio as part of an effort to compare the economics of their current incumbent provider vs. similar services provisioned in the cloud. © 2009 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction and distribution of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Although Gartner's research may discuss legal issues related to the information technology business, Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice. WHAT YOU NEED TO KNOW Enterprise instant messaging (IM) has emerged to become an infrastructure component in enterprises.
    [Show full text]
  • A Comparison Between Inter-Asterisk Exchange Protocol and Jingle Protocol: Session Time
    Engineering, Technology & Applied Science Research Vol. 6, No. 4, 2016, 1050-1055 1050 A Comparison Between Inter-Asterisk eXchange Protocol and Jingle Protocol: Session Time H. S. Haj Aliwi N. K. A. Alajmi P. Sumari K. Alieyan School of Computer Sciences Saad Al-Abdullah Academy School of Computer Sciences National Advanced IPv6 Center Universiti Sains Malaysia for Security Sciences, Kuwait Universiti Sains Malaysia Universiti Sains Malaysia [email protected] [email protected] [email protected] [email protected] Abstract—Over the last few years, many multimedia conferencing sessions. Such applications are Gtalk, Talkonaut, and Hangouts and Voice over Internet Protocol (VoIP) applications have been [7]. developed due to the use of signaling protocols in providing video, audio and text chatting services between at least two participants. II. BACKGROUND This paper compares between two widely common signaling protocols: InterAsterisk eXchange Protocol (IAX) and the extension of the eXtensible Messaging and Presence Protocol A. IAX Protocol (Jingle) in terms of delay time during call setup, call teardown, In 2004, Mark Spencer created the Inter-Asterisk eXchange and media sessions. (IAX) protocol for asterisk that performs VoIP signaling [22]. IAX is supported by a few other softswitches, (Asterisk Private Keywords-multimedia conferencing; VoIP; signaling protocols; Branch eXchange) PBX systems [23], and softphones [18]. Jingle; IAX Any type of media (Video, audio, and document conferencing) can be managed, controlled and transmitted through the I. INTRODUCTION Internet Protocol (IP) networks based on IAX protocol [25]. With the appearance of numerous multimedia conferencing IAX2 is considered to be the current version of IAX.
    [Show full text]
  • XEP-0234: Jingle File Transfer
    XEP-0234: Jingle File Transfer Peter Saint-Andre Lance Stout mailto:xsf@stpeter:im mailto:lance@andyet:com xmpp:peter@jabber:org xmpp:lance@lance:im http://stpeter:im/ 2019-06-19 Version 0.19.1 Status Type Short Name Deferred Standards Track jingle-ft This specification defines a Jingle application type for transferring a file from one entity to another. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
    [Show full text]
  • Listener Feedback #170
    Security Now! Transcript of Episode #409 Page 1 of 40 Transcript of Episode #409 Listener Feedback #170 Description: Steve and Leo discuss the week's major security events and discuss questions and comments from listeners of previous episodes. They tie up loose ends, explore a wide range of topics that are too small to fill their own episode, clarify any confusion from previous installments, and present real world 'application notes' for any of the security technologies and issues we have previously discussed. High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-409.mp3 Quarter size (16 kbps) mp3 audio file URL: http://media.GRC.com/sn/sn-409-lq.mp3 SHOW TEASE: It's time for Security Now!. Steve Gibson is here. What a great show ahead. Questions, answers. We'll talk more about PRISM, more insight there. You've got to stay tuned. This is the show to keep your privacy and security up. Security Now! is next. Leo Laporte: This is Security Now! with Steve Gibson, Episode 409, recorded June 19th, 2013: Your questions, Steve's answers, #170. It's time for Security Now!, the post-NSA edition. Steve Gibson is here, our Explainer in Chief, the guy who does all the security and privacy and is really our guru in that realm. Hello, Steve. Good to see you. Steve Gibson: Hey, Leo. Great to be with you again. And we have largely, as expected, a follow-up to last week's blockbuster theory of how PRISM works, as I expected. Actually I probably had double the number of email that I normally pull from the mailbag, which would have only been in half of the period of time.
    [Show full text]
  • Sailpoint Direct Connectors Administration and Configuration Guide for Version 7.3
    SailPoint Direct Connectors Version 7.3 Administration and Configuration Guide Copyright © 2018 SailPoint Technologies, Inc., All Rights Reserved. SailPoint Technologies, Inc. makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. SailPoint Technologies shall not be liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Restricted Rights Legend. All rights are reserved. No part of this document may be published, distributed, reproduced, publicly displayed, used to create derivative works, or translated to another language, without the prior written consent of SailPoint Technologies. The information contained in this document is subject to change without notice. Use, duplication or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 for DOD agencies, and subparagraphs (c) (1) and (c) (2) of the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 for other agencies. Regulatory/Export Compliance. The export and re-export of this software is controlled for export purposes by the U.S. Government. By accepting this software and/or documentation, licensee agrees to comply with all U.S. and foreign export laws and regulations as they relate to software and related documentation. Licensee will not export or re-export outside the United States software or documentation, whether directly or indirectly, to any Prohibited Party and will not cause, approve or otherwise intentionally facilitate others in so doing.
    [Show full text]
  • Risk of Public Disclosure: Learning from Willy Wonka
    Issue 20, 16 December 2014 WhiteNews Global corporate espionage news Editorial: WhiteRock Updates: All About Privacy 2 Threat: Are LinkedIn Contacts Trade Secrets? 3 News: $400 Bn Military Espionage; Code Fishing 4 News: Falcani Black List; Football Whistleblower 5 Feature: Willy Wonka’s Lessons in Espionage 6-7 Technology: Hearing Aid for Corporate Spies 8-9 Extra: FBI’s Untold Story; Spy on Your Rival 10-11 Letter From America: Spying Breakfast Club 12 Exclusive Reporting for WhiteRock’s Clients Risk of Public Disclosure: Learning from Willy Wonka Our feature story is seemingly seasonal and light-hearted, but the film ‘Charlie and the Chocolate Factory’ carries a very strong espionage message that is relevant even 50 years later. Willy Wonka was a brilliant CEO who knew that the only person who could protect his trade was himself. Wonka’s story translates superbly into today’s corporate world, and in this issue we are discussing how the contemporary big players are maintaining their edge and success over their competitors. This is equally relevant for small and medium-sized businesses, who really don’t prioritise their trade secrets, making their advantage extremely vulnerable. In the technology section we analyse the delicate matter of hearing aid systems. They’re everywhere, including in corporate meeting rooms, and nobody really considers these as a threat. We’re examining how to achieve a balance between protecting valuable corporate information without creating an embarrassing situation that in turn could lead to reputational damage! Our extra section may give you a wrong impression this time. No, we’re not teaching you how to spy, this is not our bag.
    [Show full text]