Research

Chris Hoff returned to the podcast this week to discuss the little awareness campaign we cooked up (no, he didn’t really hack me) and talk about the future of security over the next few years. I think this is one of our best episodes ever. If you’re interested in learning how us pundits look at the industry and recognize trends, you’ll want to listen to this one. Chris, Martin, and I really dig in deep on where security is headed and why. As always, you can find it at netsecpodcast.com… Share:

More on this later, but I’m starting to see the data security market splitting along two lines. One focused on protecting content in user workspaces and productivity applications. It’s starting with DLP but moving towards what I call Content Monitoring and Protection. On the other side of data security is protecting content in business applications- from your web application stack to internal applications and databases. I’m starting to call this Application and Database Monitoring and Protection, and Database Activity Monitoring is where it’s starting. Since we need definitions, here’s my first stab for ADMP: Products that monitor all activity in a business application and database, identify and audit users and content, and, based on central policies, protect data based on content, context, and/or activity. For CMP, I’m sticking with my DLP definition (DLP is a terrible term, but I’m not going to fight the market): Products that, based on central policies, identify, monitor, and protect data at rest, in motion, and in use through deep content analysis. Share:

Chris Hoff and I decided to have a little fun and fake some back and forth exploits to highlight some security risks. It’s nearing the end of the year; either crunch time for some of you, or boring time for the rest. We figured a little humor couldn’t hurt in either case. We decided to blow this open early so it doesn’t get away from us. The attack Chris described could clearly work, but I’m surprised more people didn’t pick up the holes. While I do have a home automation system (but no cameras) I don’t know of any that use SCADA-based technologies. Then again, SCADA is going all IP so it might not be a stretch to define my system that way. For the record, I use an Insteon system but haven’t finished implementation yet. Bonus points to the commenters that noticed there’s no way I’d have a yard with that much green in Phoenix. The idea of the Quicktime rtsp attack was completely real. Until Apple released the patch a day or so ago, the only defense was avoiding clicking on potentially hostile links. I trust Chris, and would click on most things he sends me. Outbound filtering (which I do one one of my machines) could block the request unless it directed me to an unusual port; something Chris is capable of. The idea of pwning my workstation is dead on- and one reason I often recommend SCADA workstations be isolated from the Internet. I don’t have to take over your SCADA network if I can take over the workstation and do whatever I want when you aren’t looking. We were planning on highlighting a few other attack vectors in the next few days. Among them was a fake pretexting of Chris’s phone (we had a viable way for me to get his SSN) and username/password sniffing from wireless access points. All are common vectors that even us security pros are a little lax with sometimes. I suspect most of you enjoyed this, and we’ll come up with something more creative for April 1. Share:

My second monthly column is up over at Dark Reading; The Perils of Predictions & Predicting Perils. This is not your ordinary year-end prediction special. Here’s an excerpt: As the end of the year approaches, a strange phenomenon begins. As we relax and prepare for the holidays, we feel a strange compulsion to predict the future. For some, this compulsion is so overwhelming that it bursts the bounds of late night family dinners and explodes onto the pages of blogs, magazines, newspapers and the ever-dreaded year-end specials on TV. Ah, year’s end. Legions of armchair futurists slobber over their keyboards, spilling obvious dribble that they either predict every year until it finally happens or is so nebulous that they claim success if a butterfly flaps its wings in Liechtenstein. As you can tell, I’ve never been the biggest fan of these year-end predictions, especially in the security business. Since the days of the slide rule, scores of pundits have consistently, inaccurately predicted a devastating SCADA attack or the next big worm. Instead, I focus on two major threat trends and the security innovation they are inspiring. My favorite line in the column is near the end, so I’ll pull it out: Vulnerability scanning, secure software development, and programmer security training cannot solve the Web application security problem. I’ll leave you with two words: anti-exploitation, but you should really go read the article. Share:

Here I am, about 30 hours away from home, and my home automation system is freaking out. Why does stuff like this only happen when I’m on the road? Time to whip out my copy of How To Prepare For The Robot Uprising. I guess I know what I’ll be fixing this weekend… Share:

Oh no he didn’t! http://rationalsecurity.typepad.com/blog/2007/12/breaking-news-s.html I should be crossing the border back to the US in about 12 hours. Share:

Ah, the wonders of year end predictions. We just couldn’t help ourselves, so we invited Chris Hoff, our favorite prognosticator, to join us. This week focuses on the negative trends affecting security, and Chris will be joining us again next week to finish up with the positive. As always, show notes and podcast link are over at NetSecPodcast.com. Share:

Looks like the ipfw rules project that Chris is leading is pretty popular. We’ve set up a permanent link that we’ll redirect to the latest version as we keep refining this thing. You can find it here. Thanks again to everyone who has helped on this project: windexh8er: http://www.slash32.com/ Rob Lee: http://thnetos.wordpress.com/ Josh Chris Pepper http://www.extrapepperoni.com/ Share:

  There’s been a lot going on in the industry since we last covered the Data Security Lifecycle, and it’s been far too long since the previous post. Today we’ll finish off our discussion of the controls technologies, and in our next post we’ll discuss supportive technologies, like Identity and Access Management and network encryption, that don’t fit neatly into the lifecycle itself. Since it’s been a while, here are links to the rest of the series: The Data Security Lifecycle Create and Store Technologies Use and Share Technologies The final two phases, Archive and Destroy, involve fewer technologies; making this one of the shorter posts. I’m sure at least a few of you will appreciate the brevity. 200712111207 Archive Encryption: As data migrates to archived storage, especially tape and other removable media, the risk of exposure through physical loss increases. In most cases losing a copy of data doesn’t result in any disclosure, but since you can’t definitively confirm that the data is safe you have to act as if it has been disclosed. This often leads to breach disclosures or other regulatory and reputation consequences. Inline Tape Encryption: An inline network appliance to automatically compress and encrypt data as it is transferred to a tape drive or library. Solutions currently exist for fiber channel, iSCSI, and TCP/IP, with support for all major tape protocols. Support for mainframe protocols may be possible with virtual tape adapters. Best suited for quickly encrypting existing infrastructure. Tape Drive Encryption: Hardware encryption built into the tape drive, sometimes requiring use of special tapes. Key management is typically more difficult than when using an inline appliance, mostly due to weak vendor offerings. Users state a strong preference for drive encryption in the long term, and key management is expected to improve over time, especially with the adoption of interoperability standards. Backup Software Encryption: Software encryption built into the backup tool. Performance is significantly worse than when using hardware encryption, but for lower-volume backups (especially in distributed environments) it’s often sufficient. Users are advised to be careful when choosing this option to make sure they can effectively retain and manage keys over the life of the tapes. Mainframe Tape Encryption- Hardware Accelerated: Some mainframes are able to use hardware crytographic accelerator cards in combination with tape encryption software. This eliminates the need for adapters or encrypted drives when creating mainframe tapes. Accelerator card support is included as an option in backup software from multiple vendors, often obviating the need to additional encryption software. Third-Party Software Encryption: Third-party encryption software designed to work with one or more backup software packages. Some products offer performance that exceeds that of encryption built into backup software, with superior key management, or support for multiple backup packages in a heterogenous environment. Inline SAN/NAS Encryption: An inline network appliance or feature of a SAN controller to encrypt all data moving to mass storage. Protects against physical loss of drives when SAN or NAS is used for archival storage, but does not offer separation of duties nor protection from network and software attacks. Hard Drive Encryption (Drive Level): When hard drives are used for archival storage, drive level encryption may protect data from physical loss. As with inline SAN/NAS encryption it does not protect against network or software level attacks. Requires external key management. Field-Level Encryption: Data already encrypted in a database is still secure in archives. In some cases, you may consider encrypting data normally left unencrypted in a live database when it moves to an archived database. Software Encryption: For file and media encryption. Covered in the Store section. Also usable for archived storage, including CD/DVDs. Asset Management: Since you don’t know if it’s been lost or misplaced, simply losing track of archival media can result in negative losses similar to a breach. The majority of public breach disclosures are the result of lost media (including laptops and tapes) that may or may not have ended up in the hands of the bad guys. Asset management tools, including software, tagging, and tracking technologies, reduce the risk of lost media. Destroy Crypto-Shredding: Deliberate destruction of all encryption keys essentially destroys the data until (if ever) the encryption protocol used is broken or capable of being brute-forced within a reasonable time period. This is sufficient for nearly every use case in a private enterprise, but shouldn’t be considered acceptable for highly sensitive government data. Encryption tools must have this as a specific feature to absolutely ensure that the keys are unrecoverable. Dedicated enterprise key management tools may be needed. Disk/Free-Space Wiping: Software or hardware designed to destroy data on hard drives and other media. At a minimum the tool should overwrite all possible space on the media 1-3 times, and 7 times is recommended for especially sensitive data. Merely formatting over data is not sufficient. Secure wiping is highly recommended for any systems with sensitive data that are sold or reused, especially laptops and desktops. File-level secure deletion tools exist when it’s necessary to destroy just a portion of data in active storage, but are not as reliable as a full media wipe. Physical Destruction: The possibilities for physically destroying media are only limited by your imagination, but break out into two categories: Degaussing: Use of strong magnets to scramble magnetic media like hard drives and backup tapes. Dedicated solutions should be used to ensure data is unrecoverable, and it’s highly recommended you confirm the efficiency of a degaussing tool by randomly performing forensic analysis on wiped media. Physical Destruction: Complete physical destruction of media, focusing on shredding actual magnetic media (platters or tape). Content Discovery: When truly sensitive data reaches end-of-life, you need to make sure that the destroyed data is really destroyed. Use of content discovery tools helps ensure that no copies or versions of the data remain accessible in the enterprise. Considering how complex our storage, archive, and backup strategies are today, this can’t absolutely guarantee the data is unrecoverable, but it does reduce the risk of subsequent retrieval.

Based on extensive feedback, these rules are now much improved over the initial draft. Thanks, all! All the versions of this post are getting out of hand, so Rich has provided a permanent URL for the current Leopard ipfw post for future reference. Please use that link, so future visitors get the latest and greatest. Chris DO NOT USE THESE RULES without customizing them first! Version: 2007/12/12 For more information, see http://securosis.com/2007/11/15/ipfw-rules/ & http://securosis.com/2007/11/16/ipfw-rules-20071116-revision/#comments These rules MUST be customized to your requirements. In particular, if you have a private home network (behind an AirPort Base Station, Linksys WRT54G, etc.), change “10.42.24.0/24” below to your private network range; duplicate rules with different ranges, if use use this computer on multiple networks. Additionally, allow only ports you actually use; block unused ports. Thanks to: Rich Mogull http://securosis.com windexh8er: http://www.slash32.com/ Rob Lee: http://thnetos.wordpress.com/ Josh Chris Pepper http://www.extrapepperoni.com/ Apple (Server Admin is a good way to create an ipfw ruleset) http://www.apple.com/server/macosx/ FreeBSD (where Apple got ipfw) http://www.freebsd.org/ We don’t really want this, but it’s unavoidable on Mac OS X Server, so document it here (serialnumberd). 100 allow udp from any 626 to any dst-port 626 Let me talk to myself over the loopback. add 200 allow ip from any to any via lo0 Loopback traffic on a ‘real’ interface is bogus. add 300 deny log logamount 1000 ip from any to 127.0.0.0/8 Block multicast unless you need it. add 400 deny log logamount 1000 ip from 224.0.0.0/4 to any in If we let a conversation begin, let it continue. Let my clients go! add 500 allow tcp from any to any out keep-state add 510 allow udp from any to any out keep-state Block replies, if we don’t recall initiating the conversation. add 520 deny log tcp from any to any established in Allow DHCP responses (keep-state can’t handle DHCP broadcasts). add 600 allow udp from any to any src-port 67 dst-port 68 in Do you never need fragmented packets? add 700 deny udp from any to any in frag Let yourself ping. add 1000 allow icmp from 10.42.24.0/24 to any icmptypes 8 Server Admin provides these by default. add 1100 allow icmp from any to any icmptypes 0 add 1110 allow igmp from any to any mDNS (Bonjour) from trusted local networks (fill in your own, preferably non-standard, networks after ‘from’). For Back to My Mac, you might need this from ‘any’. add 5000 allow udp from 10.42.24.0/24 to any dst-port 5353 add 5010 allow udp from 10.42.24.0/24 5353 to any dst-port 1024-65535 in ssh – should be restricted to trusted networks if at all possible; if open to the Internet, make sure you don’t have “PermitRootLogin yes” in sshd_config (at least use PermitRootLogin without-password”, please!) add 5200 allow tcp from any to any dst-port 22 iTunes music sharing add 5300 allow tcp from 10.42.24.0/24 to any dst-port 3689 AFP add 5400 allow tcp from 10.42.24.0/24 to any dst-port 548 HTTP (Apache); HTTPS add 5500 allow tcp from any to any dst-port 80 add 5510 allow tcp from any to any dst-port 443 L2TP VPN – is this complete? add 5600 allow udp from any to any dst-port 1701 add 5610 allow esp from any to any add 5620 allow udp from any to any dst-port 500 add 5630 allow udp from any to any dst-port 4500 iChat: local add 5700 allow tcp from 10.42.24.0/24 to any dst-port 5298 add 5710 allow udp from 10.42.24.0/24 to any dst-port 5298 add 5720 allow udp from 10.42.24.0/24 to any dst-port 5297,5678 Server Admin SSL (Mac OS X Server only) add 5800 allow tcp from 10.42.24.0/24 to any dst-port 311 add 5810 allow tcp from 10.42.24.0/24 to any dst-port 427 add 5820 allow udp from 10.42.24.0/24 to any dst-port 427 syslog – uncommon add 5900 allow udp from 10.42.24.0/24 to any dst-port 514 ipp (CUPS printing) add 6000 allow tcp from 10.42.24.0/24 to any dst-port 631 MTU discovery add 10000 allow icmp from any to any icmptypes 3 Source quench add 10100 allow icmp from any to any icmptypes 4 Ping out; accept ping answers. add 10200 allow icmp from any to any icmptypes 8 out add 10210 allow icmp from any to any icmptypes 0 in Allow outbound traceroute. add 10300 allow icmp from any to any icmptypes 11 in My default policy: log and drop anything that hasn’t matched an allow rule above add 65534 deny log logamount 1000 ip from any to any Hard-coded default allow rule (compiled into Darwin kernel) add 65535 allow ip from any to any Share: