I’m excited to announce PDFrate: a website that provides malicious document identification using machine learning based on metadata and structural features. The gory details of the underlying mechanisms will be presented at ACSAC 2012.
I’ve been working on this research since 2009, which was a year where the stream of PDF 0-days being leveraged by targeted attackers was nearly unbroken. I’ve refined the underlying techniques to a place where they are very effective in real operations and are addressed rigorously enough for academic acceptance. Note that I originally designed this for the purpose of detecting APT malicious documents but have found it to be largely effective on broad based crimeware PDFs also. Furthermore, it is pretty effective at distinguishing between the two. I can speak from personal experience that mechanisms underlying PDFrate provide a strong compliment to signature and dynamic analysis detection mechanisms.
Those that are interested should head over to the pdfrate site and check out the “about” page in particular which explains the mechanisms and points to some good examples.
PDFrate demonstrates a well refined mechanism for detecting malicious documents. This currently operates on PDF documents. I am close to extending this to office documents. But I see this paradigm extending much farther than just malicious documents. I see wise (and deep) selection of features and machine learning being effective for many things other things such as emails, network transactions such as HTTP, web pages, and other file formats such as SWF and JAR.
I’m happy to provide the PDFrate service to the community so that others can leverage (and critique) this mechanism. Providing this as a service is a really good way for others to be able to use it because it removes a lot of the difficulty of implementation and configuration, the hardest part of which is collecting and labeling a training set. High quality training data is critical for high quality classification and this data is often hard for a single organization/individual to compile. While the current data sets/classifiers provided on the site are fine for detecting similar attacks, there is room for improvement and generalization which I hope will come from community submissions and ratings. So please vote on submissions, malicious or not, as this will speed the development and evolution of a community driven classifier. This service could benefit from some additional recent targeted PDFs.
In addition to the classification that PDFrate provides, it also provides one of the best document metadata extraction capabilities that I’ve seen. While there are many tools for PDF analysis, the metadata and structure extraction capabilities used by PDFrate provide a great mix of speed, simplicity, robustness, saliency, and transparency. Even if you aren’t sold on using PDFrate for classification, you might see if you like the metadata it provides. Again, the about provides illustrative examples.
I hope this service is useful to the community. I look forward to describing in depth in December at ACSAC!
Showing posts with label apt. Show all posts
Showing posts with label apt. Show all posts
Saturday, September 15, 2012
Saturday, March 26, 2011
Passive Network Monitoring of Strong Authentication
There’s been a fair amount of consternation and FUD concerning the effectiveness of “strong authentication” in defending against APT. For example, in their M-trends 2011 report, Mandiant has demonstrated how smart cards are being subverted. If that isn’t bad enough, RSA has recently revealed that they’ve been victim of attacks that they believe are attributed to APT and which resulted in attackers getting access to information that may weaken the effectiveness of SecureID.
Unfortunately, like most people blogging about these issues, I can’t provide any more authoritative information on the topic other than to say that based on my personal experience, targeting and subverting strong authentication mechanisms is a common practice for some targeted, persistent attackers. It’s hard to predict the impact of any of these weaknesses. Additionally, people who have found out the hard way usually aren’t particularly open about sharing their hard knocks.
Nevertheless, I’d like to advance the suitability of passive network monitoring as a method for helping to audit authentication, especially strong authentication mechanisms. While auditing is more properly conducted using logs provided by the devices that actually perform authentication (and authorization, access control, etc if you want to be pedantic), there are real operational and organization issues that may well make passive network monitoring one of the most effective means of gathering the information necessary to perform auditing of strong authentication.
The vast majority of password based authentication mechanisms bundle the username with the password and provide both to the server either in the clear or encrypted. It is possible to provide the username in the clear and the password encrypted which would improve monitoring capabilities at the possible expense of privacy. In general, this bundling of credentials is done because confidentiality is provided through mechanisms that operate at a different layer of the stack: ex. username and password sent through SSL tunnel.
On the other hand, many authentication mechanisms provide the username/user identifier in the clear. For these protocols, passive network monitoring provides the ability to collect information necessary to provide some amount of auditing of user activity. In this post I advance two quick and dirty examples of how this information could be collected. For and simplicity’s and brevity’s sake, I’ll focus solely on collecting usernames. I’ve chosen two protocols that are very frequently used in conjunction with the strong authentication mechanisms: RADIUS and SSL/TLS client certificate authentication.
RADIUS isn’t exactly as the most secure authentication protocol in the world. Since it has some serious weaknesses, it’s normally not used over hostile networks (like the internet). However, it is frequently used internally to organizations. In fact, it is very frequently used in conjunction with strong credentials such as RSA SecureID. One nice thing about RADIUS is that the username is passed in the clear in authentication requests. As such it’s pretty simple to build a monitoring tool to expose this data to auditing.
In my example of monitoring RADIUS, I’ll use this packet capture taken from the testing data sets for libtrace.
In my experience tcpdump is very useful for monitoring and parsing older and simpler protocols, especially ones that usually don’t span multiple packets, like DNS or RADIUS. The following is shows how tcpdump parses one RADIUS authentication request:
/usr/sbin/tcpdump -nn -r radius.pcap -s 0 -v "dst port 1812" -c 1
reading from file radius.pcap, link-type EN10MB (Ethernet)
18:42:58.228064 IP (tos 0x0, ttl 64, id 47223, offset 0, flags [DF], proto: UDP (17), length: 179) 10.1.12.20.1034 > 192.107.171.165.1812: RADIUS, length: 151
Access Request (1), id: 0x2e, Authenticator: 36ea5ffd15130961caafc039b5909d34
Username Attribute (1), length: 6, Value: test
NAS IP Address Attribute (4), length: 6, Value: 10.1.12.20
NAS Port Attribute (5), length: 6, Value: 0
Called Station Attribute (30), length: 31, Value: 00-02-6F-21-EC-52:CRCnet-test
Calling Station Attribute (31), length: 19, Value: 00-02-6F-21-EC-5F
Framed MTU Attribute (12), length: 6, Value: 1400
NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
Connect Info Attribute (77), length: 22, Value: CONNECT 0Mbps 802.11
EAP Message Attribute (79), length: 11, Value: .
Message Authentication Attribute (80), length: 18, Value: ...eE.*.B.._..).
Note that we intentionally haven’t turned the verbosity up all the way. While there’s a lot of other good info in there, let say we only want to extract the UDP quad and the username and then send them to our SIMS so we can audit them. Assuming a configuration of syslog that sends logs somewhere to be audited appropriately, the following demonstrates how to do so:
tcpdump -nn -r radius.pcap -s 0 -v "dst port 1812" | awk '{ if ( $1 ~ "^[0-9][0-9]:" ) { print SRC" "DST" "USER; SRC=$18; DST=$20; USER="" }; if ( $0 ~ " Username Attribute" ) { USER=$NF } }' | logger -t radius_request
This example generates syslogs that appears as follows:
Mar 26 14:45:15 monitor radius_request: 10.1.12.20.1034 192.107.171.165.1812: test
Mar 26 14:45:15 monitor radius_request: 10.1.12.20.1034 192.107.171.165.1812: test
Mar 26 14:45:15 monitor radius_request: 10.1.12.20.1034 192.107.171.165.1812: test
I’ve done no significant validation to ensure that it’s complete, but this very well could be used on a large corporate network as is. Obviously, you’d need to replace the -r pcapfile with the appropriate -i interface.
Another opportunity for simple passive monitoring is SSL/TLS when a client certificate is used. It is very common for this mechanism to be used to authenticate users with either soft or hard (ie. smart card) certificates to web sites. This mechanism relies on PKI which involves the use of a public and private key. While the private key should never be transferred over the network, and in many cases they never leave smart cards, the public keys are openly shared. In the case of SSL/TLS client certificate based authentication the public key, along with other information such as the client user identification, is passed in the clear during authentication as the client certificate.
To have data for this example, I generated my own. I took the following steps based on the wireshark SSL wiki:
openssl req -new -x509 -out server.pem -nodes -keyout privkey.pem -subj /CN=localhost/O=pwned/C=US
openssl req -new -x509 -nodes -out client.pem -keyout client.key -subj /CN=Foobar/O=pwned/C=US
openssl s_server -ssl3 -cipher AES256-SHA -accept 4443 -www -CAfile client.pem -verify 1 -key privkey.pem
#start another shell
tcpdump -i lo -s 0 -w ssl_client.pcap "tcp port 4443"
#start another shell
(echo GET / HTTP/1.0; echo ; sleep 1) | openssl s_client -connect localhost:4443 -ssl3 -cert client.pem -key client.key
#kill tcpdump and server
#fix pcap by converting back to 443 and fixing checksums (offload problem)
tcprewrite --fixcsum --portmap=4443:443 --infile=ssl_client.pcap --outfile=ssl_client_443.pcap
You can download the resulting pcap here.
The client certificate appears as follows:
$ openssl x509 -in client.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b0:cc:6b:94:b4:83:0f:78
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=Foobar, O=pwned, C=US
Validity
Not Before: Mar 26 13:13:12 2011 GMT
Not After : Apr 25 13:13:12 2011 GMT
Subject: CN=Foobar, O=pwned, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e5:d6:78:cd:95:4e:89:0c:88:bd:78:98:26:86:
0b:f1:be:df:85:98:a2:93:c1:66:65:44:d2:aa:08:
69:2d:4c:a9:9d:50:08:79:1d:58:6e:6d:b4:2b:24:
ca:37:90:d6:91:9f:6d:73:5f:51:5a:10:af:f0:ce:
85:85:d6:e4:42:7b:ca:b0:af:0c:52:8b:60:1c:5b:
3f:54:10:cc:c4:35:18:a8:a6:a7:c8:ae:df:b7:ab:
a9:d9:20:cf:f7:5c:43:01:2e:12:cf:96:45:87:e7:
7e:87:f7:5e:8f:25:23:1b:ee:bd:0a:79:48:07:99:
ba:cc:68:16:53:43:56:e9:a1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
BD:C2:84:BF:76:17:B7:15:BC:2F:8C:7E:A6:E6:18:B1:47:60:A3:B6
X509v3 Authority Key Identifier:
keyid:BD:C2:84:BF:76:17:B7:15:BC:2F:8C:7E:A6:E6:18:B1:47:60:A3:B6
DirName:/CN=Foobar/O=pwned/C=US
serial:B0:CC:6B:94:B4:83:0F:78
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
4c:28:ea:47:20:38:d5:17:dd:cf:aa:f8:13:3e:d0:5f:cf:05:
7d:c7:a1:c3:f4:3e:d7:db:56:f7:d4:d6:d6:c6:f4:5c:47:5b:
99:f6:9c:23:2d:dc:75:ab:51:8b:96:df:26:3b:9e:59:8f:2c:
08:d1:84:bf:4f:98:65:b4:0f:b7:32:9d:2f:eb:d9:a5:a6:69:
b6:75:ce:03:f4:ad:3b:f2:e6:3a:a1:ff:44:ea:8a:98:40:34:
cc:dd:e0:d8:35:0e:8b:97:20:30:e4:7b:07:52:98:63:11:32:
5e:6e:cb:c7:f1:10:67:1c:cd:e2:03:3a:99:98:8b:2f:f8:94:
03:6f
For auditing, we are interested in extracting the CN, which in this case is “Foobar”. As the client certificate is transferred over the network, the CN appears as follows:
000002e0 00 3f 0d 00 00 37 02 01 02 00 32 00 30 30 2e 31 |.?...7....2.00.1|
000002f0 0f 30 0d 06 03 55 04 03 13 06 46 6f 6f 62 61 72 |.0...U....Foobar|
00000300 31 0e 30 0c 06 03 55 04 0a 13 05 70 77 6e 65 64 |1.0...U....pwned|
00000310 31 0b 30 09 06 03 55 04 06 13 02 55 53 0e 00 00 |1.0...U....US...|
Immediately preceding the string “Foobar” is following sequence (in hex):
06 03 55 04 03 13 06
I’m not 100% sure what the "06 03" is for, but I believe this to be invariant in client certificates (if not, this example needs fixing). The "55 04 03" is indicative of the following data being a CN. This is an x509/ASN.1 thing where this sequence maps to the OID 2.5.4.3. The "13" can vary among a few common values (it specifies the data type) and the "06" indicates the length of the data (6 ASCII characters). Using this knowledge of SSL certificates we can create a tool to extract and log all CNs as follows:
$ mkdir /dev/shm/ssl_client_streams
$ cd /dev/shm/ssl_client_streams/
$ vortex -r ssl_client_443.pcap -S 0 -C 10240 -g "svr port 443" | xargs -t -I+ pcregrep -o -H "\x06\x03\x55\x04\x03..[A-Za-z0-9]{1,100}" + | sed -r "s/\x06\x03\x55\x04\x03../ /" | sed 's/c/ /' | logger -t client_cert
This generates logs as follows:
Mar 26 15:26:05 sr2s4 client_cert: 127.0.0.1:41143 127.0.0.1:443: localhost1
Mar 26 15:26:05 sr2s4 client_cert: 127.0.0.1:41143 127.0.0.1:443: localhost1
Mar 26 15:26:05 sr2s4 client_cert: 127.0.0.1:41143 127.0.0.1:443: Foobar1
If you are new to vortex, check out my vortex howto series. Basically we’re snarfing the first 10k of SSL streams transferred from the client to the server as files then analyzing them. Note that since we’re pulling all CNs out of all the certificates in the certificate chain provided by the client, we’re getting not only “Foobar” but “localhost” who is the CA in this case. Also note the trailing garbage we were too lazy to remove.
While this works, this is a little too dirty even for me. The biggest problem is that the streams which are snarfed by vortex are never purged. Second, we’re doing a lot of work in an inefficient manner on each SSL stream, even those that don’t include client certs.
Let’s refactor this slightly. First, we’re going to immediately weed out all stream we don’t want look at. In this example I’m looking for client certs in general, but you could easily change signature to be the CA for the certificates which you are interested in monitoring. Ex. “Pwned Org CA”:
$ vortex -e -r ssl_client_443.pcap -S 0 -C 10240 -g "svr port 443" | xargs pcregrep -L "\x06\x03\x55\x04\x03" | xargs rm
That will leave all the streams which we want to inspect in the current dir. If we do something like the following in an infinite loop or very frequent cron job, then we’ll do the logging and purging we need:
find -cmin +1 -type f | while read file
do
pcregrep -o -H "\x06\x03\x55\x04\x03..[A-Za-z0-9]{1,100}" $file | sed -r "s/\x06\x03\x55\x04\x03../ /" | sed 's/c/ /' | logger -t client_cert
rm $file
done
This implementation is also probably suitable for use on a large network or pretty close to it.
For these examples, it’s assumed that the logs are streamed to a log storage, aggregation, or correlation tool for real time auditing or for historical forensics. I would not be surprised if there were flaws in the examples as presented, so use at your own risk or perform the validation and tweaking necessary for your environment. These examples are intended to be merely that—to show the feasibility. While I’ve discussed two specific protocols/mechanisms there are others that lend themselves to passive network monitoring as well as many that don’t.
In this post I’ve shown how passive network monitoring could be used to help audit the use or misuse of strong authentication mechanisms. I’ve given quick and dirty examples which are probably suitable or are close to something that would be suitable for use on enterprise networks. Notwithstanding the weaknesses in my examples, I hope they provide ideas for what can be done to “trust, but verify” strong authentication mechanisms through data collection done on passive network sensors.
Unfortunately, like most people blogging about these issues, I can’t provide any more authoritative information on the topic other than to say that based on my personal experience, targeting and subverting strong authentication mechanisms is a common practice for some targeted, persistent attackers. It’s hard to predict the impact of any of these weaknesses. Additionally, people who have found out the hard way usually aren’t particularly open about sharing their hard knocks.
Nevertheless, I’d like to advance the suitability of passive network monitoring as a method for helping to audit authentication, especially strong authentication mechanisms. While auditing is more properly conducted using logs provided by the devices that actually perform authentication (and authorization, access control, etc if you want to be pedantic), there are real operational and organization issues that may well make passive network monitoring one of the most effective means of gathering the information necessary to perform auditing of strong authentication.
The vast majority of password based authentication mechanisms bundle the username with the password and provide both to the server either in the clear or encrypted. It is possible to provide the username in the clear and the password encrypted which would improve monitoring capabilities at the possible expense of privacy. In general, this bundling of credentials is done because confidentiality is provided through mechanisms that operate at a different layer of the stack: ex. username and password sent through SSL tunnel.
On the other hand, many authentication mechanisms provide the username/user identifier in the clear. For these protocols, passive network monitoring provides the ability to collect information necessary to provide some amount of auditing of user activity. In this post I advance two quick and dirty examples of how this information could be collected. For and simplicity’s and brevity’s sake, I’ll focus solely on collecting usernames. I’ve chosen two protocols that are very frequently used in conjunction with the strong authentication mechanisms: RADIUS and SSL/TLS client certificate authentication.
RADIUS
RADIUS isn’t exactly as the most secure authentication protocol in the world. Since it has some serious weaknesses, it’s normally not used over hostile networks (like the internet). However, it is frequently used internally to organizations. In fact, it is very frequently used in conjunction with strong credentials such as RSA SecureID. One nice thing about RADIUS is that the username is passed in the clear in authentication requests. As such it’s pretty simple to build a monitoring tool to expose this data to auditing.
In my example of monitoring RADIUS, I’ll use this packet capture taken from the testing data sets for libtrace.
In my experience tcpdump is very useful for monitoring and parsing older and simpler protocols, especially ones that usually don’t span multiple packets, like DNS or RADIUS. The following is shows how tcpdump parses one RADIUS authentication request:
/usr/sbin/tcpdump -nn -r radius.pcap -s 0 -v "dst port 1812" -c 1
reading from file radius.pcap, link-type EN10MB (Ethernet)
18:42:58.228064 IP (tos 0x0, ttl 64, id 47223, offset 0, flags [DF], proto: UDP (17), length: 179) 10.1.12.20.1034 > 192.107.171.165.1812: RADIUS, length: 151
Access Request (1), id: 0x2e, Authenticator: 36ea5ffd15130961caafc039b5909d34
Username Attribute (1), length: 6, Value: test
NAS IP Address Attribute (4), length: 6, Value: 10.1.12.20
NAS Port Attribute (5), length: 6, Value: 0
Called Station Attribute (30), length: 31, Value: 00-02-6F-21-EC-52:CRCnet-test
Calling Station Attribute (31), length: 19, Value: 00-02-6F-21-EC-5F
Framed MTU Attribute (12), length: 6, Value: 1400
NAS Port Type Attribute (61), length: 6, Value: Wireless - IEEE 802.11
Connect Info Attribute (77), length: 22, Value: CONNECT 0Mbps 802.11
EAP Message Attribute (79), length: 11, Value: .
Message Authentication Attribute (80), length: 18, Value: ...eE.*.B.._..).
Note that we intentionally haven’t turned the verbosity up all the way. While there’s a lot of other good info in there, let say we only want to extract the UDP quad and the username and then send them to our SIMS so we can audit them. Assuming a configuration of syslog that sends logs somewhere to be audited appropriately, the following demonstrates how to do so:
tcpdump -nn -r radius.pcap -s 0 -v "dst port 1812" | awk '{ if ( $1 ~ "^[0-9][0-9]:" ) { print SRC" "DST" "USER; SRC=$18; DST=$20; USER="" }; if ( $0 ~ " Username Attribute" ) { USER=$NF } }' | logger -t radius_request
This example generates syslogs that appears as follows:
Mar 26 14:45:15 monitor radius_request: 10.1.12.20.1034 192.107.171.165.1812: test
Mar 26 14:45:15 monitor radius_request: 10.1.12.20.1034 192.107.171.165.1812: test
Mar 26 14:45:15 monitor radius_request: 10.1.12.20.1034 192.107.171.165.1812: test
I’ve done no significant validation to ensure that it’s complete, but this very well could be used on a large corporate network as is. Obviously, you’d need to replace the -r pcapfile with the appropriate -i interface.
SSL/TLS Client Certificate
Another opportunity for simple passive monitoring is SSL/TLS when a client certificate is used. It is very common for this mechanism to be used to authenticate users with either soft or hard (ie. smart card) certificates to web sites. This mechanism relies on PKI which involves the use of a public and private key. While the private key should never be transferred over the network, and in many cases they never leave smart cards, the public keys are openly shared. In the case of SSL/TLS client certificate based authentication the public key, along with other information such as the client user identification, is passed in the clear during authentication as the client certificate.
To have data for this example, I generated my own. I took the following steps based on the wireshark SSL wiki:
openssl req -new -x509 -out server.pem -nodes -keyout privkey.pem -subj /CN=localhost/O=pwned/C=US
openssl req -new -x509 -nodes -out client.pem -keyout client.key -subj /CN=Foobar/O=pwned/C=US
openssl s_server -ssl3 -cipher AES256-SHA -accept 4443 -www -CAfile client.pem -verify 1 -key privkey.pem
#start another shell
tcpdump -i lo -s 0 -w ssl_client.pcap "tcp port 4443"
#start another shell
(echo GET / HTTP/1.0; echo ; sleep 1) | openssl s_client -connect localhost:4443 -ssl3 -cert client.pem -key client.key
#kill tcpdump and server
#fix pcap by converting back to 443 and fixing checksums (offload problem)
tcprewrite --fixcsum --portmap=4443:443 --infile=ssl_client.pcap --outfile=ssl_client_443.pcap
You can download the resulting pcap here.
The client certificate appears as follows:
$ openssl x509 -in client.pem -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
b0:cc:6b:94:b4:83:0f:78
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=Foobar, O=pwned, C=US
Validity
Not Before: Mar 26 13:13:12 2011 GMT
Not After : Apr 25 13:13:12 2011 GMT
Subject: CN=Foobar, O=pwned, C=US
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:e5:d6:78:cd:95:4e:89:0c:88:bd:78:98:26:86:
0b:f1:be:df:85:98:a2:93:c1:66:65:44:d2:aa:08:
69:2d:4c:a9:9d:50:08:79:1d:58:6e:6d:b4:2b:24:
ca:37:90:d6:91:9f:6d:73:5f:51:5a:10:af:f0:ce:
85:85:d6:e4:42:7b:ca:b0:af:0c:52:8b:60:1c:5b:
3f:54:10:cc:c4:35:18:a8:a6:a7:c8:ae:df:b7:ab:
a9:d9:20:cf:f7:5c:43:01:2e:12:cf:96:45:87:e7:
7e:87:f7:5e:8f:25:23:1b:ee:bd:0a:79:48:07:99:
ba:cc:68:16:53:43:56:e9:a1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
BD:C2:84:BF:76:17:B7:15:BC:2F:8C:7E:A6:E6:18:B1:47:60:A3:B6
X509v3 Authority Key Identifier:
keyid:BD:C2:84:BF:76:17:B7:15:BC:2F:8C:7E:A6:E6:18:B1:47:60:A3:B6
DirName:/CN=Foobar/O=pwned/C=US
serial:B0:CC:6B:94:B4:83:0F:78
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
4c:28:ea:47:20:38:d5:17:dd:cf:aa:f8:13:3e:d0:5f:cf:05:
7d:c7:a1:c3:f4:3e:d7:db:56:f7:d4:d6:d6:c6:f4:5c:47:5b:
99:f6:9c:23:2d:dc:75:ab:51:8b:96:df:26:3b:9e:59:8f:2c:
08:d1:84:bf:4f:98:65:b4:0f:b7:32:9d:2f:eb:d9:a5:a6:69:
b6:75:ce:03:f4:ad:3b:f2:e6:3a:a1:ff:44:ea:8a:98:40:34:
cc:dd:e0:d8:35:0e:8b:97:20:30:e4:7b:07:52:98:63:11:32:
5e:6e:cb:c7:f1:10:67:1c:cd:e2:03:3a:99:98:8b:2f:f8:94:
03:6f
For auditing, we are interested in extracting the CN, which in this case is “Foobar”. As the client certificate is transferred over the network, the CN appears as follows:
000002e0 00 3f 0d 00 00 37 02 01 02 00 32 00 30 30 2e 31 |.?...7....2.00.1|
000002f0 0f 30 0d 06 03 55 04 03 13 06 46 6f 6f 62 61 72 |.0...U....Foobar|
00000300 31 0e 30 0c 06 03 55 04 0a 13 05 70 77 6e 65 64 |1.0...U....pwned|
00000310 31 0b 30 09 06 03 55 04 06 13 02 55 53 0e 00 00 |1.0...U....US...|
Immediately preceding the string “Foobar” is following sequence (in hex):
06 03 55 04 03 13 06
I’m not 100% sure what the "06 03" is for, but I believe this to be invariant in client certificates (if not, this example needs fixing). The "55 04 03" is indicative of the following data being a CN. This is an x509/ASN.1 thing where this sequence maps to the OID 2.5.4.3. The "13" can vary among a few common values (it specifies the data type) and the "06" indicates the length of the data (6 ASCII characters). Using this knowledge of SSL certificates we can create a tool to extract and log all CNs as follows:
$ mkdir /dev/shm/ssl_client_streams
$ cd /dev/shm/ssl_client_streams/
$ vortex -r ssl_client_443.pcap -S 0 -C 10240 -g "svr port 443" | xargs -t -I+ pcregrep -o -H "\x06\x03\x55\x04\x03..[A-Za-z0-9]{1,100}" + | sed -r "s/\x06\x03\x55\x04\x03../ /" | sed 's/c/ /' | logger -t client_cert
This generates logs as follows:
Mar 26 15:26:05 sr2s4 client_cert: 127.0.0.1:41143 127.0.0.1:443: localhost1
Mar 26 15:26:05 sr2s4 client_cert: 127.0.0.1:41143 127.0.0.1:443: localhost1
Mar 26 15:26:05 sr2s4 client_cert: 127.0.0.1:41143 127.0.0.1:443: Foobar1
If you are new to vortex, check out my vortex howto series. Basically we’re snarfing the first 10k of SSL streams transferred from the client to the server as files then analyzing them. Note that since we’re pulling all CNs out of all the certificates in the certificate chain provided by the client, we’re getting not only “Foobar” but “localhost” who is the CA in this case. Also note the trailing garbage we were too lazy to remove.
While this works, this is a little too dirty even for me. The biggest problem is that the streams which are snarfed by vortex are never purged. Second, we’re doing a lot of work in an inefficient manner on each SSL stream, even those that don’t include client certs.
Let’s refactor this slightly. First, we’re going to immediately weed out all stream we don’t want look at. In this example I’m looking for client certs in general, but you could easily change signature to be the CA for the certificates which you are interested in monitoring. Ex. “Pwned Org CA”:
$ vortex -e -r ssl_client_443.pcap -S 0 -C 10240 -g "svr port 443" | xargs pcregrep -L "\x06\x03\x55\x04\x03" | xargs rm
That will leave all the streams which we want to inspect in the current dir. If we do something like the following in an infinite loop or very frequent cron job, then we’ll do the logging and purging we need:
find -cmin +1 -type f | while read file
do
pcregrep -o -H "\x06\x03\x55\x04\x03..[A-Za-z0-9]{1,100}" $file | sed -r "s/\x06\x03\x55\x04\x03../ /" | sed 's/c/ /' | logger -t client_cert
rm $file
done
This implementation is also probably suitable for use on a large network or pretty close to it.
For these examples, it’s assumed that the logs are streamed to a log storage, aggregation, or correlation tool for real time auditing or for historical forensics. I would not be surprised if there were flaws in the examples as presented, so use at your own risk or perform the validation and tweaking necessary for your environment. These examples are intended to be merely that—to show the feasibility. While I’ve discussed two specific protocols/mechanisms there are others that lend themselves to passive network monitoring as well as many that don’t.
In this post I’ve shown how passive network monitoring could be used to help audit the use or misuse of strong authentication mechanisms. I’ve given quick and dirty examples which are probably suitable or are close to something that would be suitable for use on enterprise networks. Notwithstanding the weaknesses in my examples, I hope they provide ideas for what can be done to “trust, but verify” strong authentication mechanisms through data collection done on passive network sensors.
Saturday, September 18, 2010
Are Targeted Attacks on Industry Cyberwar?
I’m writing this post to try to enter the conversation on cyberwar, etc. My motivation in doing so is not only to share my opinions on the topic, but also to add my witness to the few others out there which testify that targeted attacks pose a real and extant threat to our long term national prosperity.
Before I start, I need to clarify my viewpoint. I’m a technical person. I do technical work--like programming computers. I don’t have any political, social, or economic influence. I do have a lot of operational experience doing incident response, especially against highly sophisticated attacks. However, since my current and past employers and universities don’t allow me to speak about specifics of attacks; I can only cite general observations and trends. I stand very little to gain from the comments I’ll be making. My primary goal is to help shape public opinion.
Throughout this article, I’ll be speaking about highly targeted, persistent attacks perpetrated by well organized attack groups for the apparent purpose of stealing sensitive information including trade secrets. Many people use the term Advanced Persistent Threat (APT) to describe this category of attackers. Some people use it to describe some specific subset (which they often imply isn’t a strict subset) of this attack class, and as such, use it as a proper noun. Even though many imply some coherent rationale for their grouping, they usually won’t elucidate in public. I tend to use terms like targeted attacks and persistent attackers to ensure people understand I’m talking about the general attack class. That being said, the vast majority of what has been said by people in the know about APT applies to what I’ll be saying, regardless of whether you consider APT a general attack class or specific attack group. Just to be explicit, examples of APT discussions that I believe to be on the mark are those by Mike Cloppert and Richard Bejtlich. On the other hand, examples of wantonly ignorant discussions about APT include those by Mcaffe and Damballa. One quick litmus test is that if someone supposedly discussing APT closely relates the activity to botnets, identity theft, or insider threat, they’re not talking about the same thing I am.
Most of my discussion will focus around highly targeted attacks for the purpose of compromising sensitive information, especially against industry. I’ll intentionally avoid speculating on important issues such as the ability of terrorists to use vulnerable computer systems to cause mass disruption and destruction. The one thing I will say is that there are a lot of projections about how information systems could be exploited for malicious intent. Many of these are still hypothetical. APT attacks are real today and are becoming more prevalent as time passes.
One of the most disturbing aspects of highly targeted and persistent attacks is that these attacks are becoming more common against private industry. Governments have always had to worry about spies breaking into their systems, and have supposedly been developing systems to counter APT level threats for some time. Private industry isn’t used to having to defend against APT class attacks. Companies like Google are being taken off guard. These highly targeted attacks are resulting in information being compromised that normally isn’t--things like trade secrets and proprietary information. This is really scary. The perpetrators aren’t going after credit cards or SSNs, they’re going after trade secrets. Many people consider this sort of information one of the most valuable classes of assets in the US economy. The use of this information by competitors represents a serious threat to the long term prosperity of any information based company, and by extension, the competitiveness of the US economy. This is real scary. Even the military types recognize the risk. I think it demonstrates some serious means/ends inversion, but when military types start talking about threats to US prosperity inhibiting our ability to conduct war, we ought to listen. We need to remember that self defense is merely a means to an end of freedom, peace, and prosperity. Highly targeted attacks don’t just endanger short term national security; they are a serious threat to the US’s long term peace and prosperity. Throughout this post, I’m going to be focusing primarily on attacks against industry.
Are targeted, persistent attackers waging cyberwar? This is a hard question. First, modern society has confounded the meaning of war, using it for things like “Cold War”, “War on Terror”, and even “War on Christmas”. It’s hard to clearly define what warfare is.
Clearly, cyber- (e.g. something related to computers or networking) is used pervasively in modern warfare. Militaries have driven many of the developments in technology and communication that are now used by civilians. The military uses computers, networks, and robots extensively to conduct warfare. While using cyber- in this context probably lines up with other prefixes such as modern- (e.g. using gunpowder) and chemical-, this doesn’t comprise all of what most people mean when they say cyberwar, including the US military.
The US military has applied a much broader meaning to cyberwar: defining it a battle space or domain much like land, air and sea. I’m not sure I fully agree with the rationale behind this definition, but it’s theirs to make. However, using this definition, targeted, persistent attacks with the apparent goal of collection of sensitive information, doesn’t line up with cyberwar, because no disruption occurs. Using US government parlance, this activity is probably better categorized as cyber-espionage.
If persistent, targeted attacks seeking sensitive information aren’t classed as warfare, maybe they are appropriately classed as cyber-espionage. Recently, Gen. Michael Hayden spoke at Blackhat on this very subject. What he said seems to be basically in line with the rest of what the US government has said on these topics. His basic assertion was that intelligence gathering isn’t cyberwar. He basically said that attacks targeting sensitive information like what I’ve been speaking of are just part of business as usual, at least for cyber-spies. He expounds the partitioning of the cyber domain into 3 sub-domains: CND (defense--stopping the other two), CNE (exploitation--for espionage), and CNA (attack--for disruption or destruction). A lot of what he said makes sense, as he dispels a lot of FUD. At the very least, most of what he said is technically correct.
A couple months ago, I would have agreed with this categorization of APT attacks as cyber-espionage. Then I listened to this podcast. Something Rob Lee said struck a cord with me. He said, in short, that information is an asset over which modern wars are being fought, much like the riches of land or gold in previous centuries. I’d never thought of information as the end of warfare, simply as the means. I think this way of looking at targeted attacks warrants more discussion. What if cyberwar isn’t just about aggressors using IT as a means to conduct warfare? What if the purpose of cyberwar is to rest highly valuable information away from the enemy, just like land or gold in traditional warfare? This isn’t information warfare, because the information targeted is not necessarily about warfare. Attacks targeting industry trade secrets aren’t espionage by most people’s definition because the secrets being taken aren’t military or political in nature--they are largely economic. This is essentially economic espionage.
It’s a shame that people in industry have used the term piracy for actions that are more equitable to petty theft. If it wasn’t already used, cyber-piracy seems like a good way to describe the theft of sensitive information of economic value using military-like force. That’s really what’s happening to industry now. Persistent attackers are forcibly stealing highly valuable trade secrets. One of the reasons I’d like to compare this to naval piracy is that it must be perpetrated by a military-like force and because it is usually best answered with military or para-military force. I can visualize trade secrets being exfiltrated by hackers as gold or other goods being carried off by pirates in ships. The value of the data lost due to targeted attacks is immensely high, but is not normally discussed and it is easy to conceal. Regardless, if the value of the data stolen from private industry through targeted attacks was known, it would probably be considered a justifiable reason to wage a war against the perpetrators.
One thing that many people seem to get preoccupied with is the issue of attribution for highly targeted attacks. Many facets of these attacks make it very unlikely that the attacks are perpetrated merely by organized crime without some level of support or tolerance by national governments. For example, highly persistent attackers usually target information that is not highly liquid and as such could only be of value to a small set of possible markets. Are these attacks directly sponsored, indirectly guided, or loosely condoned by foreign nations? Most of us will never know that answer. For most people, it really doesn’t matter. The actions that should be taken to solve the targeted attack problem don’t change that much regardless of how much foreign government support is behind these attacks. Lay people should be pushing for diplomatic, legal, and possibly military pressure to stop them.
Numerous open sources have implicated China in targeted attacks. My favorites include the NG report on PRC cyber-warfare and CNE and Shadows in the Clouds. The attacks on Google earlier this year and the subsequent response by Google is probably the best known public example. The most compelling evidence of Chinese involvement is that Chinese human rights activists were targeted by these attacks. It is hard to imagine anyone other than a Chinese supporter having adequate motivation to conduct this sort of attack. Of course, this doesn’t mean that the attacks are perpetrated by agents of the Chinese government. Indeed, the Chinese government often claims that they are victims of hacking themselves. Clearly the Chinese government has other high priority issues to address, such as ensuring that the constitutionally granted right to free speech is protected.
That being said, I think the focus on China is a little myopic. I find it hard to believe that all targeted attacks on industry are from one source. Even if they are, how long it will stay that way?
As mentioned previously, the extent of the damage caused by targeted persistent attacks is probably great enough to justify a war. If there’s one element missing from cyberwar, it’s our response. I’ve heard the terms cyber-Pearl Harbor and cyber-9/11 bandied about, but up to this point, there has not been a single decisive attack and associated response that even comes close to earning these titles. I doubt such an event will ever occur associated with targeted attacks on industry. Sure, terrorists and the like may well perpetrate an event that might earn an appellation of cyber-9/11. Terrorists intentionally perpetrate highly visible and dramatic attacks, but APT attacks are exactly the opposite: they are stealthy and deceptively mundane in methods. Unlike terrorists, whose goal is to gain attention, targeted, persistent attackers seem to prefer keeping things quiet. To make matters worse, most of the victims of these attacks like to keep their losses secret also. In the past, I’ve discussed how keeping targeted attacks secret stifles the development of technical solutions.
From everything I can tell, the US is not fighting back to protect industry from targeted, persistent cyber attacks. The military is trying hash out their internal turf wars about who will own the cyber domain. Beyond that, the US government is still trying to figure out who, if anyone, is going to help defend industry against cyber threats. Based on the recent reports of a huge breach in the government’s classified networks, it appears the government and military is struggling to defend its own networks. While DHS claims to have a division dedicated to cyber security, it appears that they are not concerned about the theft of trade secrets from industry, preferring to focus their efforts on protecting critical infrastructure from attacks like those terrorists would like to be able to perpetrate. Defending industry from targeted attacks is not a battle anyone is openly fighting, even though industry is getting roughed up.
Returning to the title of this post, do targeted attacks on industry constitute cyberwar? Probably not, especially if there is no reciprocation. Is it espionage? Not really, at least not according most peoples’ definition, because the data targeted isn’t directly related to the government but is largely economic in nature. If I were going to put targeted, persistent attacks on industry under a single moniker, I’d label them as “Economic Espionage”.
A major motivation in writing this post is to voice my concern about a very serious threat to our long term prosperity and to add my voice to the others claiming that these attacks are real: they are happening today at an alarming rate. I normally don’t like doing it this way, but I’ve pointed out a serious problem without providing any suggestions for remedying it. I hope to provide my thoughts on what needs to be done in a future post. Targeted attacks on industry are real. They pose a serious threat to our long term prosperity.
Before I start, I need to clarify my viewpoint. I’m a technical person. I do technical work--like programming computers. I don’t have any political, social, or economic influence. I do have a lot of operational experience doing incident response, especially against highly sophisticated attacks. However, since my current and past employers and universities don’t allow me to speak about specifics of attacks; I can only cite general observations and trends. I stand very little to gain from the comments I’ll be making. My primary goal is to help shape public opinion.
Targeted, Persistent Attacks
Throughout this article, I’ll be speaking about highly targeted, persistent attacks perpetrated by well organized attack groups for the apparent purpose of stealing sensitive information including trade secrets. Many people use the term Advanced Persistent Threat (APT) to describe this category of attackers. Some people use it to describe some specific subset (which they often imply isn’t a strict subset) of this attack class, and as such, use it as a proper noun. Even though many imply some coherent rationale for their grouping, they usually won’t elucidate in public. I tend to use terms like targeted attacks and persistent attackers to ensure people understand I’m talking about the general attack class. That being said, the vast majority of what has been said by people in the know about APT applies to what I’ll be saying, regardless of whether you consider APT a general attack class or specific attack group. Just to be explicit, examples of APT discussions that I believe to be on the mark are those by Mike Cloppert and Richard Bejtlich. On the other hand, examples of wantonly ignorant discussions about APT include those by Mcaffe and Damballa. One quick litmus test is that if someone supposedly discussing APT closely relates the activity to botnets, identity theft, or insider threat, they’re not talking about the same thing I am.
Most of my discussion will focus around highly targeted attacks for the purpose of compromising sensitive information, especially against industry. I’ll intentionally avoid speculating on important issues such as the ability of terrorists to use vulnerable computer systems to cause mass disruption and destruction. The one thing I will say is that there are a lot of projections about how information systems could be exploited for malicious intent. Many of these are still hypothetical. APT attacks are real today and are becoming more prevalent as time passes.
Attacks on Industry
One of the most disturbing aspects of highly targeted and persistent attacks is that these attacks are becoming more common against private industry. Governments have always had to worry about spies breaking into their systems, and have supposedly been developing systems to counter APT level threats for some time. Private industry isn’t used to having to defend against APT class attacks. Companies like Google are being taken off guard. These highly targeted attacks are resulting in information being compromised that normally isn’t--things like trade secrets and proprietary information. This is really scary. The perpetrators aren’t going after credit cards or SSNs, they’re going after trade secrets. Many people consider this sort of information one of the most valuable classes of assets in the US economy. The use of this information by competitors represents a serious threat to the long term prosperity of any information based company, and by extension, the competitiveness of the US economy. This is real scary. Even the military types recognize the risk. I think it demonstrates some serious means/ends inversion, but when military types start talking about threats to US prosperity inhibiting our ability to conduct war, we ought to listen. We need to remember that self defense is merely a means to an end of freedom, peace, and prosperity. Highly targeted attacks don’t just endanger short term national security; they are a serious threat to the US’s long term peace and prosperity. Throughout this post, I’m going to be focusing primarily on attacks against industry.
Cyberwar?
Are targeted, persistent attackers waging cyberwar? This is a hard question. First, modern society has confounded the meaning of war, using it for things like “Cold War”, “War on Terror”, and even “War on Christmas”. It’s hard to clearly define what warfare is.
Clearly, cyber- (e.g. something related to computers or networking) is used pervasively in modern warfare. Militaries have driven many of the developments in technology and communication that are now used by civilians. The military uses computers, networks, and robots extensively to conduct warfare. While using cyber- in this context probably lines up with other prefixes such as modern- (e.g. using gunpowder) and chemical-, this doesn’t comprise all of what most people mean when they say cyberwar, including the US military.
The US military has applied a much broader meaning to cyberwar: defining it a battle space or domain much like land, air and sea. I’m not sure I fully agree with the rationale behind this definition, but it’s theirs to make. However, using this definition, targeted, persistent attacks with the apparent goal of collection of sensitive information, doesn’t line up with cyberwar, because no disruption occurs. Using US government parlance, this activity is probably better categorized as cyber-espionage.
Cyber-Espionage?
If persistent, targeted attacks seeking sensitive information aren’t classed as warfare, maybe they are appropriately classed as cyber-espionage. Recently, Gen. Michael Hayden spoke at Blackhat on this very subject. What he said seems to be basically in line with the rest of what the US government has said on these topics. His basic assertion was that intelligence gathering isn’t cyberwar. He basically said that attacks targeting sensitive information like what I’ve been speaking of are just part of business as usual, at least for cyber-spies. He expounds the partitioning of the cyber domain into 3 sub-domains: CND (defense--stopping the other two), CNE (exploitation--for espionage), and CNA (attack--for disruption or destruction). A lot of what he said makes sense, as he dispels a lot of FUD. At the very least, most of what he said is technically correct.
Information as the End
A couple months ago, I would have agreed with this categorization of APT attacks as cyber-espionage. Then I listened to this podcast. Something Rob Lee said struck a cord with me. He said, in short, that information is an asset over which modern wars are being fought, much like the riches of land or gold in previous centuries. I’d never thought of information as the end of warfare, simply as the means. I think this way of looking at targeted attacks warrants more discussion. What if cyberwar isn’t just about aggressors using IT as a means to conduct warfare? What if the purpose of cyberwar is to rest highly valuable information away from the enemy, just like land or gold in traditional warfare? This isn’t information warfare, because the information targeted is not necessarily about warfare. Attacks targeting industry trade secrets aren’t espionage by most people’s definition because the secrets being taken aren’t military or political in nature--they are largely economic. This is essentially economic espionage.
Cyber-Piracy?
It’s a shame that people in industry have used the term piracy for actions that are more equitable to petty theft. If it wasn’t already used, cyber-piracy seems like a good way to describe the theft of sensitive information of economic value using military-like force. That’s really what’s happening to industry now. Persistent attackers are forcibly stealing highly valuable trade secrets. One of the reasons I’d like to compare this to naval piracy is that it must be perpetrated by a military-like force and because it is usually best answered with military or para-military force. I can visualize trade secrets being exfiltrated by hackers as gold or other goods being carried off by pirates in ships. The value of the data lost due to targeted attacks is immensely high, but is not normally discussed and it is easy to conceal. Regardless, if the value of the data stolen from private industry through targeted attacks was known, it would probably be considered a justifiable reason to wage a war against the perpetrators.
On Attribution
One thing that many people seem to get preoccupied with is the issue of attribution for highly targeted attacks. Many facets of these attacks make it very unlikely that the attacks are perpetrated merely by organized crime without some level of support or tolerance by national governments. For example, highly persistent attackers usually target information that is not highly liquid and as such could only be of value to a small set of possible markets. Are these attacks directly sponsored, indirectly guided, or loosely condoned by foreign nations? Most of us will never know that answer. For most people, it really doesn’t matter. The actions that should be taken to solve the targeted attack problem don’t change that much regardless of how much foreign government support is behind these attacks. Lay people should be pushing for diplomatic, legal, and possibly military pressure to stop them.
China
Numerous open sources have implicated China in targeted attacks. My favorites include the NG report on PRC cyber-warfare and CNE and Shadows in the Clouds. The attacks on Google earlier this year and the subsequent response by Google is probably the best known public example. The most compelling evidence of Chinese involvement is that Chinese human rights activists were targeted by these attacks. It is hard to imagine anyone other than a Chinese supporter having adequate motivation to conduct this sort of attack. Of course, this doesn’t mean that the attacks are perpetrated by agents of the Chinese government. Indeed, the Chinese government often claims that they are victims of hacking themselves. Clearly the Chinese government has other high priority issues to address, such as ensuring that the constitutionally granted right to free speech is protected.
That being said, I think the focus on China is a little myopic. I find it hard to believe that all targeted attacks on industry are from one source. Even if they are, how long it will stay that way?
It Takes Two to Fight
As mentioned previously, the extent of the damage caused by targeted persistent attacks is probably great enough to justify a war. If there’s one element missing from cyberwar, it’s our response. I’ve heard the terms cyber-Pearl Harbor and cyber-9/11 bandied about, but up to this point, there has not been a single decisive attack and associated response that even comes close to earning these titles. I doubt such an event will ever occur associated with targeted attacks on industry. Sure, terrorists and the like may well perpetrate an event that might earn an appellation of cyber-9/11. Terrorists intentionally perpetrate highly visible and dramatic attacks, but APT attacks are exactly the opposite: they are stealthy and deceptively mundane in methods. Unlike terrorists, whose goal is to gain attention, targeted, persistent attackers seem to prefer keeping things quiet. To make matters worse, most of the victims of these attacks like to keep their losses secret also. In the past, I’ve discussed how keeping targeted attacks secret stifles the development of technical solutions.
From everything I can tell, the US is not fighting back to protect industry from targeted, persistent cyber attacks. The military is trying hash out their internal turf wars about who will own the cyber domain. Beyond that, the US government is still trying to figure out who, if anyone, is going to help defend industry against cyber threats. Based on the recent reports of a huge breach in the government’s classified networks, it appears the government and military is struggling to defend its own networks. While DHS claims to have a division dedicated to cyber security, it appears that they are not concerned about the theft of trade secrets from industry, preferring to focus their efforts on protecting critical infrastructure from attacks like those terrorists would like to be able to perpetrate. Defending industry from targeted attacks is not a battle anyone is openly fighting, even though industry is getting roughed up.
Cyberwar?, Cyber Espionage?
Returning to the title of this post, do targeted attacks on industry constitute cyberwar? Probably not, especially if there is no reciprocation. Is it espionage? Not really, at least not according most peoples’ definition, because the data targeted isn’t directly related to the government but is largely economic in nature. If I were going to put targeted, persistent attacks on industry under a single moniker, I’d label them as “Economic Espionage”.
A major motivation in writing this post is to voice my concern about a very serious threat to our long term prosperity and to add my voice to the others claiming that these attacks are real: they are happening today at an alarming rate. I normally don’t like doing it this way, but I’ve pointed out a serious problem without providing any suggestions for remedying it. I hope to provide my thoughts on what needs to be done in a future post. Targeted attacks on industry are real. They pose a serious threat to our long term prosperity.
Monday, July 12, 2010
Reflections on Sans 4n6 and IR summit
I was really pleased with how the Sans 4n6 and IR Summit turned out. More than anything else, it was a great opportunity to network with and hear from some of the thought leaders in 4n6 and IR. Coming from a team that has a lot of experience with IR, especially APT, I probably gained more from side conversations than anything else. I was really impressed with the heavy focus on APT, and the surprisingly on point discussions about APT. Rob Lee did a great job organizing this.
Being primarily focused on IR tool development, I was happy with the high amount of respect SW developers were given. More than once, the point was made that you need really smart people creating capabilities if your (really smart) analysts are to have a chance to keep up with APT. When I romanticize my work, I fancy myself as Q, equipping our 00* analysts with the best armaments out there. Normally SW engineers are second only to end users when it comes to abuse by security folk. Overall, there was very limited bashing on end users, and even less bashing on SW engineers. I think this demonstrates the level understanding of APT at the summit including the realization that persistent attackers are best dealt with through a threat focused response, or as Mike Cloppert has so effectively expressed: security intelligence.
I was impressed with the amount of discussion on community involvement at the conference, from technical folk volunteering to help local law enforcement to the quiescent response to APT by the federal government. In fact, in my mind, the best slides of the summit should be awarded to Richard Bejtlich concerning what the US gov. should do in response to APT. If you want a discomfort chuckle, they’re definitely worth the click.
For those who haven’t found it yet, the slides are here.
Being primarily focused on IR tool development, I was happy with the high amount of respect SW developers were given. More than once, the point was made that you need really smart people creating capabilities if your (really smart) analysts are to have a chance to keep up with APT. When I romanticize my work, I fancy myself as Q, equipping our 00* analysts with the best armaments out there. Normally SW engineers are second only to end users when it comes to abuse by security folk. Overall, there was very limited bashing on end users, and even less bashing on SW engineers. I think this demonstrates the level understanding of APT at the summit including the realization that persistent attackers are best dealt with through a threat focused response, or as Mike Cloppert has so effectively expressed: security intelligence.
I was impressed with the amount of discussion on community involvement at the conference, from technical folk volunteering to help local law enforcement to the quiescent response to APT by the federal government. In fact, in my mind, the best slides of the summit should be awarded to Richard Bejtlich concerning what the US gov. should do in response to APT. If you want a discomfort chuckle, they’re definitely worth the click.
For those who haven’t found it yet, the slides are here.
Wednesday, June 23, 2010
Cloppert on Defining APT Campains
Michael Cloppert has posted another installment in his long running series on security intelligence. In his latest, Defining APT Campaigns, he discusses the how and why behind a threat focussed approach to categorizing attack activity. More importantly than the how, when combined with his previous articles in this series, he gives a clear explanation of the why.
If you are somehow responsible for responding to targeted attackers you should understand why security intelligence or a threat focussed response is so critical. This is how you consistently stop and analyze attacks before compromises occur. This is how build resilient defenses that transcend the vulnerability du jour. This is how you get a leg up on the attackers and make repeated attacks harder for them.
I have to say, when I was first exposed to security intelligence, I was a little skeptical. My thought was "that's cool we can understand so much about the attacker, but what's the point?". Well, the point is, the more visibility you have into an attack sequence, the more an attacker has to change to make the next attack successful. You can also stop attacks sooner, saving time on damage assessment and cleanup which allows you to spend more time preparing for the next attack. After seeing how effective this approach is against APT, I'm a believer. I can't count the number attacks, including 0-day exploits, that I have seen effectively mitigated because of common indicators or techniques used between attacks in the same campaign.
Lastly, he touches on the criticality of developing tools for threat focussed incident response and detection. Clearly this warms my heart.
If you are somehow responsible for responding to targeted attackers you should understand why security intelligence or a threat focussed response is so critical. This is how you consistently stop and analyze attacks before compromises occur. This is how build resilient defenses that transcend the vulnerability du jour. This is how you get a leg up on the attackers and make repeated attacks harder for them.
I have to say, when I was first exposed to security intelligence, I was a little skeptical. My thought was "that's cool we can understand so much about the attacker, but what's the point?". Well, the point is, the more visibility you have into an attack sequence, the more an attacker has to change to make the next attack successful. You can also stop attacks sooner, saving time on damage assessment and cleanup which allows you to spend more time preparing for the next attack. After seeing how effective this approach is against APT, I'm a believer. I can't count the number attacks, including 0-day exploits, that I have seen effectively mitigated because of common indicators or techniques used between attacks in the same campaign.
Lastly, he touches on the criticality of developing tools for threat focussed incident response and detection. Clearly this warms my heart.
Saturday, May 29, 2010
Security Engineering Is Not The Solution to Targeted Attacks
Recent publicity and lessons from the school of hard knocks have significantly increased the visibility of targeted attacks. Many organizations react to targeted attacks by pouring on yet more of the traditional reactive security measures that didn’t work in the first place. Many also institute draconian rules and procedures for their users. While stepping up security infrastructure and user awareness training is often necessary, it can never completely solve the targeted attack problem, at least not without inflicting unacceptably unreasonable and probably impractical restrictions on the organization’s personnel and IT infrastructure.
There’s been a fair amount of buzz about Michal Zalewski’s article entitled Security engineering: broken promises. He does a very good job of summarizing some of the open issues with security engineering. I do think he’s probably a little pessimistic, missing some opportunities to give credit and I think it’s unfair to claim security engineering has failed for not developing a unified model that can ensure security. However, he’s pulled together a lot of different facets of security engineering in a short article. The field of security engineering does need to continue to seek to eliminate vulnerabilities that are being exploited widely, and do it in an efficient manner. Much of his discussion can be generalized beyond software security to general information security.
While Zalewski didn’t address or mention APT, I’ve heard similar (but usually not so complete or well worded) rants about the failings of security best practices in regards to APT. It really pains me hear people trash security engineering, especially in the context of Aurora and similar attacks. I’ve also heard a fair amount “sky is falling” and “security best practices can’t keep you safe from APT”. Blaming security engineering for failing to stop targeted attacks doesn’t make sense when it was never a requirement of most systems. Furthermore, we don’t want security engineering alone to solve this problem anyway.
Engineering is about applying science to provide solutions that meet well defined parameters. These parameters involve all sorts of things like functionality, cost, reliability, etc. Many of these parameters are conflicting, at least apparently. Because we live in a world with scarce resources, engineering seeks to provide the optimum value for all the various parameters.
While security has some unique characteristics, it can be viewed as another parameter of a system. While I agree that if done right, security doesn’t have to be as painful as we often make it, security does often conflict with other parameters such as flexibility, cost, and functionality. As such, a wise engineer only invests as much effort in making a system secure as is required.
It amazes me that physics envy rages so strong in some people’s hearts and minds that they actually lose sight of the imperfections of both theoretical and applied physics. People who expect a comprehensive model to cover all aspects of security, much like the ever nebulous theory of everything, have a long time to wait, very possibly infinitely long, but even that is probably impossible to prove. Furthermore, many of the simple physics models are hard to actually apply in the real world due the many different phenomena that need to be modeled simultaneously. The massless, frictionless, point objects that we hear so much of in physics exercises must only exist in a vacuum, because I’ve never seen them. Practical application of physics isn’t as easy as the models often make it appear. That’s alright though. Using classic Newtonian physics works in a great many situations and helps me understand the world around me. Scientific models always have limitations in their applicability, but that doesn’t negate their value. While it quite often literally requires a group of rocket scientists, very often using a mix of multiple models and simulations, we’ve been able to do a great many things based on physics without having a theory of everything.
Formal methods are hard. Formally verifying a system is only practical on the most simple of systems. However, it has been done. Ex. flight control systems or highly secure classified systems. We refrain from formally verifying all systems we build not because we can’t or don’t know how, but because it’s just too hard. It requires too much effort and restricts the functionality and flexibility of the resulting systems too much for most people’s tastes. Most people couldn’t, or at least wouldn’t want to do their day to day work on one of these highly verified, and therefore, highly restricted systems.
While not my favorite, using risk mitigation strategies is very effective in certain circumstances. It’s useful where the risk can be quantified and accurately predicted. A prime example of this is the risk associated with identity theft. Many financial institutions effectively apply risk mitigation calculations to determine whether a given measure which will reduce losses due to identity theft will cost more to implement than just accepting the losses. As long as the losses can be accurately calculated a priori, this method is very valid.
Again, I realize that there is plenty room for improvement in the field of security engineering. Regardless, for most threats, security engineering is rather successful overall. We know how to make systems more secure than they are now, but we prefer not to. So if systems aren’t as secure as they should be, it’s usually because we didn’t design them to be secure. Sure, part of engineering is finding solutions that satisfy multiple parameters at the same time. These advances will continue to make security more compatible with ease of use and flexibility. Improved standards will continue to raise the minimum bar of security, while minimizing the additional cost of doing so. However, I believe most systems are secure enough, or at least as secure as we wanted them to be.
It should be noted that the adequacy of the security provided by most systems is not provided solely by the system itself but is supported by external factors such as legal protections. For example, the physical security of most houses is only good enough to make it difficult, well maybe even only inconvenient, for would-be burglars. The vast majority of the deterrence comes in fear of getting caught. Furthermore, insurance provides a very cost effective means of protecting your investments despite the remote risk of burglary.
The biggest problem with targeted attacks isn’t that security engineering couldn’t provide effective solutions. Our current systems aren’t secure enough to protect us from targeted attacks because we haven’t asked them to be that secure. Furthermore, I don’t think we want them to be that secure. Even if it was possible to make a machine that was 100% secure, I doubt it could ever be used for much of consequence while maintaining that level of security due to weaknesses in the environment, people, and processes.
Let’s return to the example of the residential physical security. Imagine if you took away the deterrence offered by law enforcement. It’s hard to imagine, but let’s say would-be attackers had basically no external deterrence and the only thing between them and your possessions in your house was you and your house. You’d have to go to some very extreme measures to keep your house secure. Simple locks and even an alarm system wouldn’t cut it. Basically in absence of any other deterrent, to defeat a rational burglar the defenses on your house would have to cost the attacker more to circumvent than the value that he could gain from sacking the house. This is a tough asymmetric situation where your defenses have to be perfect and the persistent burglar only has to find one weakness or one weak moment. He can try over and over again, as failed attempts don’t cost him much. It doesn’t take much imagination to see how living in a house like this wouldn’t be much fun.
Ok, now pretend you have something valuable to a small set of burglars. Let’s say you have something like a highly coveted recipe for cinnamon rolls. Let’s say a small set of burglars really want to make their own sweat buns instead of buying yours, and possibly sell them to your customers. The problem with this is that you can’t take out an insurance policy on your roll recipe very easily. How could you quantify the cost of exposure? How could you prove the secret was really lost if you suspect it was? How many times would insurance compensate you—only on the first loss or on all subsequent losses? Insurance just doesn’t work in this case. Insurance policies work great for easily replaceable items like televisions, cars, etc, but they just don’t work well for things like trade secrets.
Targeted attacks are much like the scenario laid out above. Sadly, there is little to no deterrence. Usually the information targeted is highly valuable, but not easily quantifiable. Lastly, while it technically would be possible to engineer defenses that would be effective, very few people really want to live the resulting vault in fort knox, let alone pay for the construction.
So if it’s not feasible to pursue a pure engineering solution to defend against targeted attacks, what is to be done? First of all, a lot of other non-technical solutions should be pursued. I’ll refrain from discussing legal, political, diplomatic, military, etc. solutions because most of us only have a minor influence on these domains and my experience is pretty thin in these areas. However, I do think it’s clear that in many cases, non-technical solutions would be the most effective solutions to the problem. It should also be clear by the empty public statements made by many leaders and decision makers in this realm that non-technical solutions on an international scale are going to take a while, if they ever come.
Security engineering is part of the solution. In many cases, we do need to engineer more secure solutions. We need to make security cheaper and easier. However, even with the best minds on the problem, this will only help so much. While our users need to improve their resilience to social engineering, in many cases, targeted attacks are so done so well, that I couldn’t fault a user for being duped.
Previously I discussed how keeping targeted attacks secret kills R&D. In that case, I wasn’t speaking of security engineering as applied to all IT systems, but was referring to the small subset of IT infrastructure dedicated primarily to security (ex. IDS, SIMS, etc). In that post I echoed the claim of others that threat focused response or security intelligence is one of the most effective approaches to responding to targeted attacks. Surely, this incident response approach will require some engineering of tools to support this approach, in addition to the general security engineering that will come out of proper incident response. Correctly prioritizing your engineering resources to deal with targeted attacks will often result in allocation of resources to tools that support an intelligence driven response.
I often imagine that a well functioning threat focused incident response team facing targeted attacks is much like the wolf and sheepdog cartoon. While the sheep aren’t particularly well protected, and really can’t be if they are to graze successfully, the sheepdog watches for the ever present wolf. The sheepdog keeps track of the wolf and counters his efforts directly, instead of trying to remedy every possible vulnerability. I recognize that as the sheepdog is invariably successful, this comparison is a little more ideal than reality will probably ever be. However, focusing a concentrated intelligence effort on a relatively small group of highly sophisticated attackers makes a lot of sense as long as the group of advanced attackers is small and the effort to defend against them is much higher than against other vanilla threats.
I’ve done both security engineering and engineering for security intelligence. Both have their place. Both have their success stories and both have numerous opportunities for improvement. However, blaming security engineering for the impact of targeted attacks is a herring as red as they come. A world where security engineering actually tried to solve highly targeted and determined attackers would not be a fun place in which to live. In absence of other solutions, an intelligence driven incident response model is your best bet. If I haven’t been able to convince you of this, then all I have to say is that Chewbacca lives on Endor and that just doesn’t make sense… Blaming security engineering for target attacks: that does not make sense.
There’s been a fair amount of buzz about Michal Zalewski’s article entitled Security engineering: broken promises. He does a very good job of summarizing some of the open issues with security engineering. I do think he’s probably a little pessimistic, missing some opportunities to give credit and I think it’s unfair to claim security engineering has failed for not developing a unified model that can ensure security. However, he’s pulled together a lot of different facets of security engineering in a short article. The field of security engineering does need to continue to seek to eliminate vulnerabilities that are being exploited widely, and do it in an efficient manner. Much of his discussion can be generalized beyond software security to general information security.
While Zalewski didn’t address or mention APT, I’ve heard similar (but usually not so complete or well worded) rants about the failings of security best practices in regards to APT. It really pains me hear people trash security engineering, especially in the context of Aurora and similar attacks. I’ve also heard a fair amount “sky is falling” and “security best practices can’t keep you safe from APT”. Blaming security engineering for failing to stop targeted attacks doesn’t make sense when it was never a requirement of most systems. Furthermore, we don’t want security engineering alone to solve this problem anyway.
Engineering
Engineering is about applying science to provide solutions that meet well defined parameters. These parameters involve all sorts of things like functionality, cost, reliability, etc. Many of these parameters are conflicting, at least apparently. Because we live in a world with scarce resources, engineering seeks to provide the optimum value for all the various parameters.
While security has some unique characteristics, it can be viewed as another parameter of a system. While I agree that if done right, security doesn’t have to be as painful as we often make it, security does often conflict with other parameters such as flexibility, cost, and functionality. As such, a wise engineer only invests as much effort in making a system secure as is required.
It amazes me that physics envy rages so strong in some people’s hearts and minds that they actually lose sight of the imperfections of both theoretical and applied physics. People who expect a comprehensive model to cover all aspects of security, much like the ever nebulous theory of everything, have a long time to wait, very possibly infinitely long, but even that is probably impossible to prove. Furthermore, many of the simple physics models are hard to actually apply in the real world due the many different phenomena that need to be modeled simultaneously. The massless, frictionless, point objects that we hear so much of in physics exercises must only exist in a vacuum, because I’ve never seen them. Practical application of physics isn’t as easy as the models often make it appear. That’s alright though. Using classic Newtonian physics works in a great many situations and helps me understand the world around me. Scientific models always have limitations in their applicability, but that doesn’t negate their value. While it quite often literally requires a group of rocket scientists, very often using a mix of multiple models and simulations, we’ve been able to do a great many things based on physics without having a theory of everything.
Success of Security Engineering
Formal methods are hard. Formally verifying a system is only practical on the most simple of systems. However, it has been done. Ex. flight control systems or highly secure classified systems. We refrain from formally verifying all systems we build not because we can’t or don’t know how, but because it’s just too hard. It requires too much effort and restricts the functionality and flexibility of the resulting systems too much for most people’s tastes. Most people couldn’t, or at least wouldn’t want to do their day to day work on one of these highly verified, and therefore, highly restricted systems.
While not my favorite, using risk mitigation strategies is very effective in certain circumstances. It’s useful where the risk can be quantified and accurately predicted. A prime example of this is the risk associated with identity theft. Many financial institutions effectively apply risk mitigation calculations to determine whether a given measure which will reduce losses due to identity theft will cost more to implement than just accepting the losses. As long as the losses can be accurately calculated a priori, this method is very valid.
Again, I realize that there is plenty room for improvement in the field of security engineering. Regardless, for most threats, security engineering is rather successful overall. We know how to make systems more secure than they are now, but we prefer not to. So if systems aren’t as secure as they should be, it’s usually because we didn’t design them to be secure. Sure, part of engineering is finding solutions that satisfy multiple parameters at the same time. These advances will continue to make security more compatible with ease of use and flexibility. Improved standards will continue to raise the minimum bar of security, while minimizing the additional cost of doing so. However, I believe most systems are secure enough, or at least as secure as we wanted them to be.
It should be noted that the adequacy of the security provided by most systems is not provided solely by the system itself but is supported by external factors such as legal protections. For example, the physical security of most houses is only good enough to make it difficult, well maybe even only inconvenient, for would-be burglars. The vast majority of the deterrence comes in fear of getting caught. Furthermore, insurance provides a very cost effective means of protecting your investments despite the remote risk of burglary.
Security Engineering Can’t Solve Targeted Attacks
The biggest problem with targeted attacks isn’t that security engineering couldn’t provide effective solutions. Our current systems aren’t secure enough to protect us from targeted attacks because we haven’t asked them to be that secure. Furthermore, I don’t think we want them to be that secure. Even if it was possible to make a machine that was 100% secure, I doubt it could ever be used for much of consequence while maintaining that level of security due to weaknesses in the environment, people, and processes.
Let’s return to the example of the residential physical security. Imagine if you took away the deterrence offered by law enforcement. It’s hard to imagine, but let’s say would-be attackers had basically no external deterrence and the only thing between them and your possessions in your house was you and your house. You’d have to go to some very extreme measures to keep your house secure. Simple locks and even an alarm system wouldn’t cut it. Basically in absence of any other deterrent, to defeat a rational burglar the defenses on your house would have to cost the attacker more to circumvent than the value that he could gain from sacking the house. This is a tough asymmetric situation where your defenses have to be perfect and the persistent burglar only has to find one weakness or one weak moment. He can try over and over again, as failed attempts don’t cost him much. It doesn’t take much imagination to see how living in a house like this wouldn’t be much fun.
Ok, now pretend you have something valuable to a small set of burglars. Let’s say you have something like a highly coveted recipe for cinnamon rolls. Let’s say a small set of burglars really want to make their own sweat buns instead of buying yours, and possibly sell them to your customers. The problem with this is that you can’t take out an insurance policy on your roll recipe very easily. How could you quantify the cost of exposure? How could you prove the secret was really lost if you suspect it was? How many times would insurance compensate you—only on the first loss or on all subsequent losses? Insurance just doesn’t work in this case. Insurance policies work great for easily replaceable items like televisions, cars, etc, but they just don’t work well for things like trade secrets.
Targeted attacks are much like the scenario laid out above. Sadly, there is little to no deterrence. Usually the information targeted is highly valuable, but not easily quantifiable. Lastly, while it technically would be possible to engineer defenses that would be effective, very few people really want to live the resulting vault in fort knox, let alone pay for the construction.
Alternatives to Security Engineering
So if it’s not feasible to pursue a pure engineering solution to defend against targeted attacks, what is to be done? First of all, a lot of other non-technical solutions should be pursued. I’ll refrain from discussing legal, political, diplomatic, military, etc. solutions because most of us only have a minor influence on these domains and my experience is pretty thin in these areas. However, I do think it’s clear that in many cases, non-technical solutions would be the most effective solutions to the problem. It should also be clear by the empty public statements made by many leaders and decision makers in this realm that non-technical solutions on an international scale are going to take a while, if they ever come.
Security engineering is part of the solution. In many cases, we do need to engineer more secure solutions. We need to make security cheaper and easier. However, even with the best minds on the problem, this will only help so much. While our users need to improve their resilience to social engineering, in many cases, targeted attacks are so done so well, that I couldn’t fault a user for being duped.
Previously I discussed how keeping targeted attacks secret kills R&D. In that case, I wasn’t speaking of security engineering as applied to all IT systems, but was referring to the small subset of IT infrastructure dedicated primarily to security (ex. IDS, SIMS, etc). In that post I echoed the claim of others that threat focused response or security intelligence is one of the most effective approaches to responding to targeted attacks. Surely, this incident response approach will require some engineering of tools to support this approach, in addition to the general security engineering that will come out of proper incident response. Correctly prioritizing your engineering resources to deal with targeted attacks will often result in allocation of resources to tools that support an intelligence driven response.
I often imagine that a well functioning threat focused incident response team facing targeted attacks is much like the wolf and sheepdog cartoon. While the sheep aren’t particularly well protected, and really can’t be if they are to graze successfully, the sheepdog watches for the ever present wolf. The sheepdog keeps track of the wolf and counters his efforts directly, instead of trying to remedy every possible vulnerability. I recognize that as the sheepdog is invariably successful, this comparison is a little more ideal than reality will probably ever be. However, focusing a concentrated intelligence effort on a relatively small group of highly sophisticated attackers makes a lot of sense as long as the group of advanced attackers is small and the effort to defend against them is much higher than against other vanilla threats.
I’ve done both security engineering and engineering for security intelligence. Both have their place. Both have their success stories and both have numerous opportunities for improvement. However, blaming security engineering for the impact of targeted attacks is a herring as red as they come. A world where security engineering actually tried to solve highly targeted and determined attackers would not be a fun place in which to live. In absence of other solutions, an intelligence driven incident response model is your best bet. If I haven’t been able to convince you of this, then all I have to say is that Chewbacca lives on Endor and that just doesn’t make sense… Blaming security engineering for target attacks: that does not make sense.
Tuesday, April 20, 2010
Keeping Targeted Attacks Secret Kills R&D
I’m really impressed with Google’s response to what has been coined Operation Aurora by others. I’m impressed for lots reasons. I’m impressed because they recognize the value of their intellectual property and when they realized that it was threatened, they took decisive actions to protect their interests. I think it’s sad that so many companies in a similar situation would be blinded by short sighted lust for the “emerging market” that they fail to protect themselves and fail to recognize that the same market is far from a fair or open. I’m impressed that when they apparently felt that the espionage was backed or at least condoned by the Chinese government, they called them out. Most of all, I’m happy they made this public.
That being said, I’m not too impressed that google, and the majority of the computer security industry for that matter, were taken off guard by these attacks. The level of sophistication and determination is not new nor is the type of data targeted. For the purpose of this article, when I refer to a targeted and sophisticated attacks I’m referring to attacks where one or more attacker groups repeatedly seeks to (re-)penetrate an organization’s computer systems for ends specific to the victim organization, typically exfiltration of sensitive information. These attacks are characterized by a high degree of knowledge of the victims, often a high degree of social engineering, adequate technical sophistication, and high degree of organization/coordination on the part of the attackers. I refrain from using the term advanced persistant threat (APT), because while it has had a fairly precise meaning among the people using the term for some time, the meaning has been blurred quite a bit of late. For the purposes of this article, the specific identities of the attackers, including affiliation or backing by nation-states, is not important. A few public reports of these sorts of attacks go back to at least the 2003-2005 timeframe, probably earlier, but that’s when I started paying attention. Maybe the one thing that is new is the type of industry targeted. I think google should have known it was coming. I’ll bet they had some warnings they chose to ignore, but I guess I can't fault them too much.
The response by the security industry to these attacks is pitiful. Many people recognize that the state of the art, including mainstream enterprise security tools, can’t stop, let alone detect, this sort of activity. While there are a few valiant incident responders who have been dealing with sophisticated targeted attacks for some time, many with a good deal of success, the security vendors have basically ignored their pleas and ideas for improved security tools. I’ve heard vendors say “You don’t want to do that” and “the market for that isn’t big enough for us to implement it”.
What has to happen for the security industry to realize they need to deal with sophisticated targeted attacks? First, organizations need to realize the value of their intellectual property. Second they need to realize that it’s at risk. I think most organizations are at this point. Third, they need to realize that conventional security wisdom, practices, and tools, won’t protect them against this, for some people new, class of attacker. Unfortunately, all too often, this epiphany only comes after personal and painful experience. Fourth, enough people need to start demanding effective solutions that vendors feel compelled to deliver them and academia recognizes the problems that need researching. Lastly, the solutions--a capable workforce, processes and practices, technology, etc need to be developed.
While there are many hindrances, one of the biggest obstacles to effectively dealing with targeted attacks is silence. While this class of attack is far from new, basically no one talks about it. While there are plenty examples of good public documentation of sophisticated attacks, ex. Businessweek E-espionage threat, NG’s report on Chinese Espionage, and Mandiant M-trends, basically no one credible steps up and confirms the validity of the data, leaving many to dismiss these reports as sensational journalism, conspiracy theories, and marketing hype. Based on solid public data, I guess I don’t blame people for questioning the reality of this threat until they experience it personally.
This code of silence related to compromises is very detrimental to solving the problem through the various available avenues: political/diplomatic, legal, and security systems including technology and people. There are a lot of legitimate reasons for not broadcasting your status as victim of a sophisticated attack and/or the type details required to help prevent future occurrences. Most of them I wouldn’t agree with, especially if everyone in the same industry/sector is in the same boat and you all know it. One of the few legitimate reasons to keep details of these attacks secret is that defending against persistent attackers is best achieved through an attacker focused or security intelligence driven approach. But how long is your threat intelligence still useful? Surely keeping specific attack data secret past a year or two doesn’t buy you much in terms of security intelligence as the most aggressive attackers change tactics and techniques more frequently than this. Hopefully it doesn't reveal too much about your capabilities either, as they need to be evolving that quickly also. Does acknowledging you’ve been attacked after your incident response is finished, or at least well under way, buy you anything in terms of threat intelligence? I don’t think so. I admire google for going public and doing something about it. I’m happy to see some public details, but more details and official acknowledgement from google would be nice. Sadly, google is right when they say they’ve already been more open that most others in the industry.
The organizations that keep targeted attacks and the details of them secret are part of the problem, or at the very least, aren’t doing everything necessary to help solve the problem. I think it’s a little hypocritical for organizations to complain about the security industry and academia not addressing this class of threat when no one will talk about the problem publicly with the requisite level of certainty and specificity.
Focusing on security R&D, there are a few things I think need to happen before the security tools industry and academia can start to address targeted attacks. The people doing R&D need to know what type of attacks are actually occurring, they need to understand the importance of a threat focused response model, and they need some decent data.
One of the major problems with current academic and applied research is that most researchers don’t understand the basics of a highly targeted attack scenario. They don’t know how serious the problem is. If you tell an academic that the sky is falling because of targeted attacks and give them a high level overview, they’ll either yawn or laugh at you. Case in point, the following hypothetical conversation:
Boots on Ground Responder: We’ve got to do something about these highly socially engineered spear-phishing attacks!
Heads in Clouds Researcher: If you graph the social network, how many nodes away is the sender from the recipient?
Boots on Ground Responder: Uh, 1. Sometimes 2. Sometimes more, it depends.
Heads in Clouds Researcher: Ok, what about the malware? Rootkit? Polymorphism? Any Red pill/Blue pill?
Boots on Ground Responder: In this case nothing like that. Just simple malware that provides minimal backdoor. Malware isn’t even packed.
Heads in Clouds Researcher: Ok, this stuff isn’t being detected by your AV, IDS, etc but it’s still making it through firewalls, proxies, etc. Any interesting data hiding techniques?
Boots on Ground Responder: No, not really. Malware evades AV because it’s never been seen before. In cases where they need to evade our IDS, they use trivial obfuscation like ceasar ciphers. Usually though, they just hide in plain sight.
Heads in Clouds Researcher: Doesn’t sound too interesting to me. Just patch your systems and tell your users not to click on unsolicited email.
Boots on Ground Responder: Yeah, right. Still, we see repeated patterns in all of these attacks. I can’t give you details, but there’s got to be a way to catch these guys.
Heads in Clouds Researcher: Ok, well I’m going to go back to musing on the trusting trust problem…
The sad part is there are some really interesting problems, true academic problems, but for the most part, academia isn’t seeing them. I don’t think it’s because academia isn’t trying to find good problems to solve, I think it’s because the interesting details aren’t being shared.
Researchers need to learn how different targeted attacks are from opportunistic attacks. They need to understand how the goals and methods differ. They need to understand how different the targeting mechanisms are. They need to understand how valuable an intelligence driven response model is. However, they won’t learn it until someone shows them.
So much conventional security wisdom and basically all academic research takes a vulnerability focused approach. The focus is on detecting and mitigating individual attacks, not persistent campaigns comprising series of attacks. That’s the best approach for many classes of attacks, but isn’t the best if determined attackers continue attacking the same target over and over again. So many other people have spoken on this topic, that I’ll defer to them and steer my ramblings toward application of these principles to security tool development. For the reader’s reference, I recommend this podcast by some of the thought leaders in this realm. If what they are saying is news to you, check out their blogs, etc.
People doing security R&D have to learn about intelligence driven incident response. While some products support this approach, almost none fully embrace it. Even worse, academia is basically mute on the topic.
One aspect of a threat focused response model that is very important for security R&D is the importance of prioritization of response. While I have seen some products and research that recognizes the importance of prioritization based on the vulnerability/exploit, basically no security R&D addresses prioritization based on intelligence or attacker identity. Given the following choice, which would you rather detect/block: A stealthy rootkit installed by a botnet for the purpose of identity theft/fraud or an email containing a link to an exploit which when visited gives a sophisticated attacker user level access to the compromised computer? Most academics and many in the security industry would take the former because of impact on the system but a small group of security professional will lean hard towards the latter because of impact to the organization’s overall mission.
Another important aspect of threat focused response is relative importance of prevention and detection. For an intelligence driven response model, detection is king, and prevention is a distant second. In fact in some cases, it might actually be beneficial to not mitigate attacker activity if the attack is or will be mitigated further in the attack sequence (or kill chain) and if blocking the attack prevents collection of further threat intelligence (ex. firewall block). On the flip side, being able to detect an attack, even if it wasn’t or couldn’t be blocked, is imperative. If you look at the bigger picture, being able to block an attack is always the best, but if you can’t or didn’t detect it in real time, detecting it in near real time often almost as good. While many don’t appreciate it, being able to do historical detections, or understanding how intrusions started, including attacker activity preceding the actual attack, is also important to an intelligence driven response.
Lastly, post unsuccessful attack analysis is almost ignored by conventional tools and research. However, successful incident responders know the importance of analyzing unsuccessful attacks and developing mitigations across all facets of the attack sequence.
People doing security R&D have to learn to build features supporting threat intelligence into their tools and research.
One of the biggest hurdles to overcome for basically any sort of research is obtaining good data. The relative dearth of data related to target attacks kills research. If you were a researcher, would you choose a problem for which there is no public data? How could you? Even if you are doing more applied R&D, getting good data isn’t so easy.
There are a couple approaches to getting data for research: you can either gather the data for yourself, or you can use someone else’s data, usually a public data set. The problem with gathering the data yourself is that most researchers will never be able to gather data on targeted attacks. By their very nature, traditional computer security collection mechanisms such as honeypots, honey monkeys, etc will not normally ever see a targeted attack, definitely not a persistent campaign of target attacks. Even the researchers and vendors that do end up seeing samples representing one phase of targeted attacks, say malware, don’t see the full attack lifecycle. How can you address all phases of the attack if you only see one?
So there are good public data sets and there are some that aren’t so great, however, it seems that once a reasonably valid data set is used, it gets used over and over again. I admire folk who put together quality data sets for the community. One infamous example in the realm of incident detection is the DARPA 99 Intrustion Detection Evaluation dataset. While probably a decent data set at the time, and while memories of winnuke, etc may well be indelibly seared into the minds of some cyber war horses, these sort attacks are about as far from targeted attacks as you can get. DARPA 99 has been used and abused for a long time, but people still use it! Why? There aren’t many other options for public data sets. Other decent options for some types of research include packet captures from events like the Defcon CTF and NSA/West Point Competition, but these events are by their very nature very poor sources for persistent and highly target attacks.
While it will be necessary to develop good data sets involving targeted attacks, it’s going to be a hard effort. First, to demonstrate a persistent attacker, you need months, even years of data. As attacks have moved up the protocol stack and have become incredibly personalized, sanitizing data is going to be a lot more difficult than scrubbing IP addresses and hostnames. To truly address targeted attacks, tools will have to be configured with information about the data and people using the computer systems (not just the computer systems themselves). What that means for researchers is that to understand the significance of a target attack, you have to understand the targeted organization and targeted individuals. Lastly, as incident responders know, to be effective, data needs to be integrated from all phases of the attack and come in all sorts of formats: logs, netflow or packet captures, malware, etc. It’s clear that a perfect public data set for target attacks will never exist, but organizations can make steps by releasing older data.
While I doubt that any quality public data sets will be coming soon, organizations need to learn the value of collecting an internal data set. By nature, Incident Responders aren’t always the most disciplined at things like collecting and labeling data for historical purposes, especially considering the conditions in which they operate. Regardless, a little bit of effort to compile historical attack data for future reference, including labeling of data, pays huge dividends both in responding to future attacks and providing good training/test data for new tools.
Keeping quiet about sophisticated targeted attacks kills, among other things, intelligence driven tool R&D. For the technology to catch up with the threat, the problem needs to be discussed publicly and more details need to be shared. Publicly sharing attack information is critical to the research and development required to catch up technologically with sophisticated attacks. If the code of silence isn't broken, incident responders will continue to flounder with mainstream security tools while security tool vendors will continue to have watershed moments.
That being said, I’m not too impressed that google, and the majority of the computer security industry for that matter, were taken off guard by these attacks. The level of sophistication and determination is not new nor is the type of data targeted. For the purpose of this article, when I refer to a targeted and sophisticated attacks I’m referring to attacks where one or more attacker groups repeatedly seeks to (re-)penetrate an organization’s computer systems for ends specific to the victim organization, typically exfiltration of sensitive information. These attacks are characterized by a high degree of knowledge of the victims, often a high degree of social engineering, adequate technical sophistication, and high degree of organization/coordination on the part of the attackers. I refrain from using the term advanced persistant threat (APT), because while it has had a fairly precise meaning among the people using the term for some time, the meaning has been blurred quite a bit of late. For the purposes of this article, the specific identities of the attackers, including affiliation or backing by nation-states, is not important. A few public reports of these sorts of attacks go back to at least the 2003-2005 timeframe, probably earlier, but that’s when I started paying attention. Maybe the one thing that is new is the type of industry targeted. I think google should have known it was coming. I’ll bet they had some warnings they chose to ignore, but I guess I can't fault them too much.
The response by the security industry to these attacks is pitiful. Many people recognize that the state of the art, including mainstream enterprise security tools, can’t stop, let alone detect, this sort of activity. While there are a few valiant incident responders who have been dealing with sophisticated targeted attacks for some time, many with a good deal of success, the security vendors have basically ignored their pleas and ideas for improved security tools. I’ve heard vendors say “You don’t want to do that” and “the market for that isn’t big enough for us to implement it”.
What has to happen for the security industry to realize they need to deal with sophisticated targeted attacks? First, organizations need to realize the value of their intellectual property. Second they need to realize that it’s at risk. I think most organizations are at this point. Third, they need to realize that conventional security wisdom, practices, and tools, won’t protect them against this, for some people new, class of attacker. Unfortunately, all too often, this epiphany only comes after personal and painful experience. Fourth, enough people need to start demanding effective solutions that vendors feel compelled to deliver them and academia recognizes the problems that need researching. Lastly, the solutions--a capable workforce, processes and practices, technology, etc need to be developed.
While there are many hindrances, one of the biggest obstacles to effectively dealing with targeted attacks is silence. While this class of attack is far from new, basically no one talks about it. While there are plenty examples of good public documentation of sophisticated attacks, ex. Businessweek E-espionage threat, NG’s report on Chinese Espionage, and Mandiant M-trends, basically no one credible steps up and confirms the validity of the data, leaving many to dismiss these reports as sensational journalism, conspiracy theories, and marketing hype. Based on solid public data, I guess I don’t blame people for questioning the reality of this threat until they experience it personally.
This code of silence related to compromises is very detrimental to solving the problem through the various available avenues: political/diplomatic, legal, and security systems including technology and people. There are a lot of legitimate reasons for not broadcasting your status as victim of a sophisticated attack and/or the type details required to help prevent future occurrences. Most of them I wouldn’t agree with, especially if everyone in the same industry/sector is in the same boat and you all know it. One of the few legitimate reasons to keep details of these attacks secret is that defending against persistent attackers is best achieved through an attacker focused or security intelligence driven approach. But how long is your threat intelligence still useful? Surely keeping specific attack data secret past a year or two doesn’t buy you much in terms of security intelligence as the most aggressive attackers change tactics and techniques more frequently than this. Hopefully it doesn't reveal too much about your capabilities either, as they need to be evolving that quickly also. Does acknowledging you’ve been attacked after your incident response is finished, or at least well under way, buy you anything in terms of threat intelligence? I don’t think so. I admire google for going public and doing something about it. I’m happy to see some public details, but more details and official acknowledgement from google would be nice. Sadly, google is right when they say they’ve already been more open that most others in the industry.
The organizations that keep targeted attacks and the details of them secret are part of the problem, or at the very least, aren’t doing everything necessary to help solve the problem. I think it’s a little hypocritical for organizations to complain about the security industry and academia not addressing this class of threat when no one will talk about the problem publicly with the requisite level of certainty and specificity.
Focusing on security R&D, there are a few things I think need to happen before the security tools industry and academia can start to address targeted attacks. The people doing R&D need to know what type of attacks are actually occurring, they need to understand the importance of a threat focused response model, and they need some decent data.
Understanding the Targeted Attack Scenario
One of the major problems with current academic and applied research is that most researchers don’t understand the basics of a highly targeted attack scenario. They don’t know how serious the problem is. If you tell an academic that the sky is falling because of targeted attacks and give them a high level overview, they’ll either yawn or laugh at you. Case in point, the following hypothetical conversation:
Boots on Ground Responder: We’ve got to do something about these highly socially engineered spear-phishing attacks!
Heads in Clouds Researcher: If you graph the social network, how many nodes away is the sender from the recipient?
Boots on Ground Responder: Uh, 1. Sometimes 2. Sometimes more, it depends.
Heads in Clouds Researcher: Ok, what about the malware? Rootkit? Polymorphism? Any Red pill/Blue pill?
Boots on Ground Responder: In this case nothing like that. Just simple malware that provides minimal backdoor. Malware isn’t even packed.
Heads in Clouds Researcher: Ok, this stuff isn’t being detected by your AV, IDS, etc but it’s still making it through firewalls, proxies, etc. Any interesting data hiding techniques?
Boots on Ground Responder: No, not really. Malware evades AV because it’s never been seen before. In cases where they need to evade our IDS, they use trivial obfuscation like ceasar ciphers. Usually though, they just hide in plain sight.
Heads in Clouds Researcher: Doesn’t sound too interesting to me. Just patch your systems and tell your users not to click on unsolicited email.
Boots on Ground Responder: Yeah, right. Still, we see repeated patterns in all of these attacks. I can’t give you details, but there’s got to be a way to catch these guys.
Heads in Clouds Researcher: Ok, well I’m going to go back to musing on the trusting trust problem…
The sad part is there are some really interesting problems, true academic problems, but for the most part, academia isn’t seeing them. I don’t think it’s because academia isn’t trying to find good problems to solve, I think it’s because the interesting details aren’t being shared.
Researchers need to learn how different targeted attacks are from opportunistic attacks. They need to understand how the goals and methods differ. They need to understand how different the targeting mechanisms are. They need to understand how valuable an intelligence driven response model is. However, they won’t learn it until someone shows them.
Supporting threat focused response
So much conventional security wisdom and basically all academic research takes a vulnerability focused approach. The focus is on detecting and mitigating individual attacks, not persistent campaigns comprising series of attacks. That’s the best approach for many classes of attacks, but isn’t the best if determined attackers continue attacking the same target over and over again. So many other people have spoken on this topic, that I’ll defer to them and steer my ramblings toward application of these principles to security tool development. For the reader’s reference, I recommend this podcast by some of the thought leaders in this realm. If what they are saying is news to you, check out their blogs, etc.
People doing security R&D have to learn about intelligence driven incident response. While some products support this approach, almost none fully embrace it. Even worse, academia is basically mute on the topic.
One aspect of a threat focused response model that is very important for security R&D is the importance of prioritization of response. While I have seen some products and research that recognizes the importance of prioritization based on the vulnerability/exploit, basically no security R&D addresses prioritization based on intelligence or attacker identity. Given the following choice, which would you rather detect/block: A stealthy rootkit installed by a botnet for the purpose of identity theft/fraud or an email containing a link to an exploit which when visited gives a sophisticated attacker user level access to the compromised computer? Most academics and many in the security industry would take the former because of impact on the system but a small group of security professional will lean hard towards the latter because of impact to the organization’s overall mission.
Another important aspect of threat focused response is relative importance of prevention and detection. For an intelligence driven response model, detection is king, and prevention is a distant second. In fact in some cases, it might actually be beneficial to not mitigate attacker activity if the attack is or will be mitigated further in the attack sequence (or kill chain) and if blocking the attack prevents collection of further threat intelligence (ex. firewall block). On the flip side, being able to detect an attack, even if it wasn’t or couldn’t be blocked, is imperative. If you look at the bigger picture, being able to block an attack is always the best, but if you can’t or didn’t detect it in real time, detecting it in near real time often almost as good. While many don’t appreciate it, being able to do historical detections, or understanding how intrusions started, including attacker activity preceding the actual attack, is also important to an intelligence driven response.
Lastly, post unsuccessful attack analysis is almost ignored by conventional tools and research. However, successful incident responders know the importance of analyzing unsuccessful attacks and developing mitigations across all facets of the attack sequence.
People doing security R&D have to learn to build features supporting threat intelligence into their tools and research.
Irrelevant Data Supports Irrelevant Research
One of the biggest hurdles to overcome for basically any sort of research is obtaining good data. The relative dearth of data related to target attacks kills research. If you were a researcher, would you choose a problem for which there is no public data? How could you? Even if you are doing more applied R&D, getting good data isn’t so easy.
There are a couple approaches to getting data for research: you can either gather the data for yourself, or you can use someone else’s data, usually a public data set. The problem with gathering the data yourself is that most researchers will never be able to gather data on targeted attacks. By their very nature, traditional computer security collection mechanisms such as honeypots, honey monkeys, etc will not normally ever see a targeted attack, definitely not a persistent campaign of target attacks. Even the researchers and vendors that do end up seeing samples representing one phase of targeted attacks, say malware, don’t see the full attack lifecycle. How can you address all phases of the attack if you only see one?
So there are good public data sets and there are some that aren’t so great, however, it seems that once a reasonably valid data set is used, it gets used over and over again. I admire folk who put together quality data sets for the community. One infamous example in the realm of incident detection is the DARPA 99 Intrustion Detection Evaluation dataset. While probably a decent data set at the time, and while memories of winnuke, etc may well be indelibly seared into the minds of some cyber war horses, these sort attacks are about as far from targeted attacks as you can get. DARPA 99 has been used and abused for a long time, but people still use it! Why? There aren’t many other options for public data sets. Other decent options for some types of research include packet captures from events like the Defcon CTF and NSA/West Point Competition, but these events are by their very nature very poor sources for persistent and highly target attacks.
While it will be necessary to develop good data sets involving targeted attacks, it’s going to be a hard effort. First, to demonstrate a persistent attacker, you need months, even years of data. As attacks have moved up the protocol stack and have become incredibly personalized, sanitizing data is going to be a lot more difficult than scrubbing IP addresses and hostnames. To truly address targeted attacks, tools will have to be configured with information about the data and people using the computer systems (not just the computer systems themselves). What that means for researchers is that to understand the significance of a target attack, you have to understand the targeted organization and targeted individuals. Lastly, as incident responders know, to be effective, data needs to be integrated from all phases of the attack and come in all sorts of formats: logs, netflow or packet captures, malware, etc. It’s clear that a perfect public data set for target attacks will never exist, but organizations can make steps by releasing older data.
While I doubt that any quality public data sets will be coming soon, organizations need to learn the value of collecting an internal data set. By nature, Incident Responders aren’t always the most disciplined at things like collecting and labeling data for historical purposes, especially considering the conditions in which they operate. Regardless, a little bit of effort to compile historical attack data for future reference, including labeling of data, pays huge dividends both in responding to future attacks and providing good training/test data for new tools.
Keeping quiet about sophisticated targeted attacks kills, among other things, intelligence driven tool R&D. For the technology to catch up with the threat, the problem needs to be discussed publicly and more details need to be shared. Publicly sharing attack information is critical to the research and development required to catch up technologically with sophisticated attacks. If the code of silence isn't broken, incident responders will continue to flounder with mainstream security tools while security tool vendors will continue to have watershed moments.
Subscribe to:
Posts (Atom)
