Data Security Governanace and Consumer Cloud Storage

2,474 views

Published on

a brief on the most popular consumer cloud storage protocols along with suggestions to mitigate the threat of data exfiltration via these services on corporate networks.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,474
On SlideShare
0
From Embeds
0
Number of Embeds
1,735
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Market penetration:Dropbox- 2008: 200,000 customers, 1.5m valuation. 2010: 2,000,000 users, 4 billion USD valuationThe purpose of this document is to look over the most popular
  • Data Security Governanace and Consumer Cloud Storage

    1. 1. Data Security Governance and Consumer Cloud StorageUnderstanding the technologies and detecting the threats
    2. 2. CCS: Definition• Consumer Cloud Storage services (CCS) are cloud-based file systems used to store, retrieve, back up and share files between multiple users and devices • Extremely popular, wide market penetration • Variety of feature differentiators between providers • Security and operational models vary by provider
    3. 3. Methodology• We’ll use a dtrace script to print out all outbound tcp connections and their associated processes and then we’ll manipulate the applications to see if we can make a correlation between function and TCP stream • Install the CCS package while running the ‘opensnoop’ dtrace debugger and capture the opensnoop output. • Start the CCS client daemon while running a tShark capture, along with opensnoop and the soconnect_mac.d dtrace script, logging the output. • Examine the resulting pcap file and extract the individual TCP sessions logged by the soconnect_mac.d script. Make note of the ports, protocols, and networks utilized in the sessions. • Using the same monitoring techniques, perform file upload, modification, and deletion operations to the directory monitored by the service and note any differences (if any). • Examine the files accessed by the process(es) to determine if any useful data or correlations can be gleaned.
    4. 4. Dropbox Client Initialization• Upon client startup: • DNS: Standard query A clientXX.dropbox.com • clientXX may be any number between 0-99 (dynamically generated by a call to /dev/urandom) • all records are CNAMES for client.dropbox.com • This is likely a way to prohibit clients from hardcoding a single IP address in a host file and thereby always directing traffic to a single login server • DNS returns list of available client login servers • All servers within the 199.47.216.0/22 subnet, specifically 199.47.216.159-174 • Server IPs are load balanced to provide load sharing over pool.
    5. 5. Dropbox Client Initialization (cont’d)• Client selects last IP address returned from the query• Client establishes TCP connection to this address on port 443 and negotiates TLS encryption• All traffic for this TCP session is now encrypted• However, we also see Dropbox connections to • 108.160.161.159 (talk.google.com) • 199.47.216.172 (block servers)
    6. 6. Dropbox Flows Local DNS Query for DNS Query clientXX.dropbox.com XX is 0-99 DNS responds with A records for AuthDNS Response and Notification Servers (below) Client Metadata Servers v-client-XY.sjc.dropbox.com Login, 199.47.216.172registrations, 199.47.216.173 Filesystem 199.47.216.174 updates 199.47.217.172 https 199.47.217.173 199.47.217.174 199.47.218.159 199.47.218.160 199.47.218.159 199.47.218.160
    7. 7. Dropbox Flows (cont’d) Upload file index & check for changes https Block Servers dl-clientX.dropbox.com (X=1-780) All hostnames resolve to Amazon S2 Cloud Storage Servers on the Upload/ following Amazon networks: downloadnew changes 204.236.128.0/17 https 174.129.0.0/16 184.72.0.0/15 23.20.0.0/14 50.16.0.0/14 107.20.0.0/14 23.20.0.0/14 75.101.128.0/17Receive update Notification Servers notifications notifyxx.dropbox.com http x = 1-40 108.160.160.0/20
    8. 8. Dropbox: Interesting Traffic (The smoking guns)• XMPP connections to talk.google.com • from="gmail.com" id="BC175DBCBFCBDADD" version="1.0" xmlns:stream=http://etherx.jabber.org/streams xmlns="jabber:client”• IP connections to a known block server
    9. 9. Detecting Dropbox on the Network• IDS signature • Cleartext registration with Google Talk servers • alert tcp $MY_NETWORK any -> $EXTERNAL_NET $HTTP_PORTS (msg:"DROPBOX.COM services in use"; flow:established,to_server; content:"/subscribe?host_int="; http_uri; content:"&ns_map="; http_uri; > content:"&ts="; http_uri; content:".dropbox.com|0d 0a|"; > classtype:policy- violation; sid:1; rev:1;)• Augment IDS with log file analysis of DNS server traffic • Some sophisticated stuff can be done here to ensure that multiple data points are being analyzed prior to alerting
    10. 10. Google Drive• The Google Drive service relies upon DNS load balancing to provide geographic and resource diversity. The Google drive client begins by querying for clientsX.google.com (where X is a randomly selected integer between 1 and 5)• The client’s local DNS server returns a CNAME of clients.l.google.com and load balanced dynamic list of 11 IP addresses in one of two IP ranges: • 74.125.236.96/28 • 173.194.36.0/28
    11. 11. Google Drive: Traffic Flows Local DNS Query forDNS Query clientsX.google.com X=1-5 DNS server responds with CNAME clients.l.google.com and load balanced dynamic A records in ranges:DNS Response 74.125.236.96/28 173.194.36.0/28 Login, Registration and Notification Serversregistrations, clients.l.google.com Filesystem 74.125.236.96/28 updates 173.194.36.0/28 https Upload file index & check for changes https Local DNS Query forDNS Query upload.drive.google.com
    12. 12. Google Drive: Traffic Flows (cont’d) DNS server responds with CNAME large-uploads.l.google.com and A records: DNS Response 74.125.131.116 74.125.131.117 Block Servers Upload/ download new changes 74.125.131.116 74.125.131.117 https Local DNS Query for DNS Query talk.google.com DNS server responds with CNAME talk.l.google.com and A records: DNS Response 74.125.131.125 74.125.133.125 Receive update XMPP Servers notifications talk.google.com http 74.125.131.125 74.125.133.125
    13. 13. Detecting Google Drive on the Network• No choice but to use a signature based upon DNS queries • alert udp any -> any 53 (msg:"DNS Query for Google Drive Upload Server"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"upload|05|drive|06|google|03|com|00"; distance:0; nocase; classtype:policy-violation; sid:2; ver:1)• Augment with host based file analysis to differentiate other Google services from Google Drive
    14. 14. Microsoft SkyDrive• Similar to Google Drive, SkyDrive relies upon Microsoft’s server and network resources shared by other Microsoft services. Client initialization begins with an DNS query to the local client’s DNS server for login.live.com. The query returns a CNAME of login.live.com.nsatc.net and eight IPv4 address records within the ranges of • 65.54.186.0/25 and • 65.54.165.128/25.
    15. 15. Microsoft SkyDrive: Traffic Flows• A mind boggling number of TCP connections • 13 HTTPs connections to various Microsoft servers within 13 seconds of usage• All connections are https only• DNS queries are for login.live.com • No way to differentiate between other services that leverage live.com
    16. 16. Detecting SkyDrive on the Network• Don’t use IDS/IPS (for now…)_ • Watch future iterations of the client releases to see if any non encrypted traffic is introduced into the flows • It may be possible to learn more about the architecture of the service as it matures (Dropbox made this easy. Google made it harder. Microsoft made it positively nightmarish).• Instead, focus on file-based analysis to detect SkyDrive usage: • ~USER/Application Data/Microsoft/SkyDrive/SkyDrive.Resources (Mac OSX) • ~USERAppDataLocalMicrosoftSkyDriveSkyDrive.Resourc es
    17. 17. Wrap Up• The increase in CCS use is not going to decline• The most popular services are treated as embedded features• These embedded features utilize the same backend as less threatening services• IPS/IDS cannot solve the problem on it’s own
    18. 18. Wrap Up (cont’d)• We have to augment InfoSec training to include reasoned arguments against using these services in the work place• We need to augment our technical controls to include file based detection instead of just network detection• Corporations should definitely consider Enterprise File Sharing Applications (Accellion, etc) to bridge the gap between user demands and the security needs of the environment.

    ×