Research

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:

I’m working on a project where I’m having to codify some of my thoughts on the rise of the data security markets, and I’m lumping in application security since I consider the line between those two disciplines far grayer than we usually admit. This is one of those great projects where I get to reuse a lot of material I’ve already posted (like the Data Security Lifecycle), and finally codify some things I’ve been talking and thinking about that I haven’t had the time to post yet. Here’s the introduction; designed to explain the rising importance of data security markets to a business audience. The last line is a prediction I’ll highlight for the attention-deficit crowd: Data and business application security will drive most of the new growth of the security market over the next 3-5 years. Nothing Earth-shattering, and probably common sense to many of you, but you might find this good fodder to help explain the rise of data security to your non-security folks. At some point I need to convert some of this into real numbers, if I can. The Rise Of Data Security Over the past few years we”ve seen a dramatic shift in the electronic threats faced by business and government, but only minor shifts in how organizations protect themselves. In the early days of the Internet, most attackers were mere experimenters or vandals, exploring connected systems and leaving behind the virtual equivalent of graffiti. The most damaging attacks tended to be worms or viruses that disrupted the ability to do business without materially affecting enterprise assets on the back end. The information security industry responded with tools focused on easing this immediate pain, securing the electronic perimeter and filtering out this bad traffic. The practice of “Information security” degraded to mere “network security” with a dash of “host security”. Products such as firewalls, IDS, and antivirus came to dominate the security market. This was a logical response to the disruptive risks at the time- attackers focused on damage and disruption using the network as the primary avenue of attack, and the industry responded with tools and technologies to keep systems running and carry out business. Beginning around five years ago the main threats began developing away from the attacks of the 1990s and focusing on profitable crime as opposed to mindless vandalism, but our approach to security failed to respond in kind. True, profitable cybercrime always existed, but it only became more common than experimentation and vandalism relatively recently. This is a natural evolution driven by three factors: Increased skill among attackers and a sufficient talent pool of technically proficient individuals willing to break the law. A growing volume of financially valuable data online- primarily personal data and corporate intellectual property. Development of criminal markets to facilitate conversion of this data to money. Bad guys now have effective skills, something to steal, and a place to sell it. Most of this crime occurs under the covers, outside the public eye. In many cases it’s because enterprises lack the fundamental capability to detect these attacks. In other cases, as opposed to a business outage that”s difficult to hide, organizations see no reason to publicize that they”ve become victims of crime, potentially putting their partners and customers at risk. Network security is very successful at limiting the risks it was developed for, but the environment has changed, and new tools and techniques are needed. These failures have been highlighted over the past 2 years by a combination of regulatory changes and a series of dramatic breaches. Since the passing of the California breach notification law in 2003 (SB 1386) there have been hundreds of reported disclosures of private information- over 500 in 2006 and 2007. The Sarbanes-Oxley act in the United States and similar laws in other nations have highlighted the importance of securing corporate financial data. The Payment Card Industry Data Security Standard (PCI-DSS) requires companies to better protect credit card data to limit financial fraud. Over 34 U.S. states and Japan have passed breach notification laws similar to California’s, with more nations expected to follow (Australia is in active debate). Other notable laws (mostly in the US) include HIPAA for healthcare, and the Gramm-Leach-Bliley Act for financial services. On the breach front, companies such as SAP and Oracle are ensnared in major industrial espionage lawsuits (Oracle vs. SAP) and nary a day passes without a new headline of supposed Chinese hackers stealing state and industrial secrets from western nations. The combination of the increase in cybercrime, changing regulations, and public exposures is increasing the attention and resources dedicated to data security. Over the next three years it’s expected that data security issues (and the related application security) will account for over 60% of new enterprise security spending- this includes spending on new technologies, and excludes maintenance of existing technologies such as firewalls and antivirus, which account for most current security costs. Data and business application security will drive most of the new growth of the security market over the next 3-5 years. Share:

Ah, the silly season of predictions. Rothman has a round up of the early entries, and I’ll have more to say on that particular subject in my monthly Dark Reading column (should be up next week). Stiennon was a little different this year- he blogged his methodology, took a few days off to ruminate, then blogged the results of his analysis. Chris Hoff described his methods to me over IM (it involves Guiness, a keyboard, and about an hour), and came to very similar results. Me? I’ve been spending a lot of time talking to clients (mostly on the vendor and investment side) about various data security markets and predicted growth rates. There’s been a ton of acquisition activity in the areas I spend most of my time on and I’m being frequently asked to predict the next “hot” market. I guess with the RSA conference delayed until April people are getting a little impatient. I won’t be making any predictions today, but like Stiennon it never hurts to share my secret sauce for making educated guesses. When I look at security markets I generally divide them into three categories which tend to correlate to hype, adoption, and investment trends. Threat/Response: These markets are driven by a rapid rise in a threat that demands an immediate response in order to effectively continue to engage in business. A jump in worm activity (around Code Red) drove firewall investments. Viruses like Melissa and LoveLetter forced wide adoption of enterprise antivirus. Huge jumps in spam forced a dramatic increase in antispam. And so on. In each case, the threat increased at a rapid enough pace to disrupt normal business operations, forcing a response. These are the markets that creep along, then suddenly explode, resulting in big numbers and year over year revenue increases in the hundreds of percent. Compliance Driven: In compliance markets the threat driving investment isn’t one of external attack, but of regulatory fines, disrupted business operations due to an inability to meet industry standards, or fears of material negative public perception due to press related to an inability to meet a standard (e.g. HIPAA). Compliance rarely, if ever, drives the same adoption rates as threat/response since daily business operations aren’t disrupted, but these markets see steady growth with increases ranging from 75% to over 100% year over year. Examples include Data Loss Prevention, Security Information and Event Management, Identity Management, and Database Activity Monitoring. More rapid growth rates are tied to solutions for problems leading to audit or compliance failures, then followed by solutions that reduce the cost of compliance, then followed by solutions that are only sometimes required for compliance or otherwise not explicitly required (like DLP). Internally Motivated: These are tools we buy to improve security, which aren’t demanded by an immediate external force. They often address threats that don’t necessarily disrupt daily business operations but often result in higher losses when they hit. The bad news is these are often the most important tools for improving security and preventing material losses, but since those incidents aren’t as “in your face” as spam or loss of services, the adoption rate is much lower. This is, of course, only part of the market evaluation process. The real trick is to predict when these market drivers will hit and markets will switch to the next (or previous) category. But if I gave everything away, no one would hire me, I’d end up just a full time blogger, and I’d have to move in with my Mom and learn to speak Klingon. Share:

I was amused to get this in the mail today. Since I’m not a total bastard, I’ve removed the header and sender’s name. From: xxxxxxx@dimacc.com Subject: Seeking an ad on your windows security page Date: December 6, 2007 2:45:09 PM GMT-07:00 To: rmogull@securosis.com Thanks for your great page on OSX vs. windows security over at http://securosis.com/2006/11/20/mac-vs-windows-security-its-a-whole-new-game-and-doesnt-matter/. I think you’ve built a great security resource and I am writing to ask if I could buy a text ad on that page for a security website. I can pay 35 dollars for the ad. Do you do paypal? Cheers, xxxxxxxxxx xxxxxxxxxx Wow. A whole $35!!!! That could like pay for almost like a few months of my web hosting!!! I could, like, buy 1/3 of a nice dinner for a girl!!!!Maybe even my wife!!!! Looking up their site I find the following: David Robertson CEO and Founder When only the best will do, DIMACC is here for you! Specializing in Website Advertising As you may already have guessed, we’re in the marketing business. The company’s founder and CEO, David Robertson, is a 1989 Harvard graduate. While attending Harvard University working towards his MBA, a class project made Dave realize what his life calling was – Advertising. He was required to set up a mock business detailing every aspect including plans to make and keep it a success. He chose to create an advertising company for his project and enjoyed it so much that he wanted to pursue it in real life. Five years later, in Maplewood, Minnesota, this dream became a reality when DIMACC took on its first client. The company’s main goal, which remains #1 today, was to do anything and everything for the client so they get the results they are after. The advertising business can be a cut-throat and hectic business to get into, but with the knowledge and experience found at DIMACC mixed with the positive atmosphere found in the work environment, it’s no wonder this company has become such a success. Well darn, Harvard! I’m impressed. What a success! They should be so proud!!!! Oh well, it’s still better than Facebook’s Beacon garbage. Share:

This is just awesome. The MPAA illegally used GPL licensed code in their University Toolkit (the license required release of the source code for any derivatives). They refused to respond to requests to comply with the license, and a developer issued a DMCA takedown notice to the MPAA’s internet service provider, who shut down the site. Share:

Adrian Lane, frequent commenter on this blog, wrote about the desire for real case studies of breaches. I’ve been spending a lot of time digging through breach statistics and all the public information on some major breaches in order to come as close as possible to root cause analysis. While I love the Attrition database and the Privacy Rights Clearing House, they are only able to enter what little data makes it into the public light. It makes for a nice Star Wars spoof, and is absolutely helpful, but it’s time we took it to the next step. In order to make really intelligent decisions on how to protect ourselves we need to perform root cause analysis on real world breaches. I’ve done the best I can on this, and have a fairly decent presentation on it, but there are serious limitations when relying on nothing but press reports, which is pretty much all we have. I’m in discussions with a very trusted organization about potentially running a detailed survey focused on how breaches really occur. The goal is to provide the community with hard data on where the bad guys are succeeding, where they are failing, what defenses work, and what defenses don’t. Real root cause analysis, on a statistically significant scale. I’m not going to ask if you think this would be useful- we all know the answer. What I’m going to ask is if you would be willing to participate. One potential poll format is an open, anonymous survey. The next option is an invitation survey (thus we’ll know you participated) but where your answers are totally anonymous. Next is participating in a focused study with interviews, but without releasing who you are or what organization you work for. The final option is a public case study (and only answer if you think the lawyers will sign off, and we know they won’t). These results will help us design our model and how to approach the security community. We all know the bad guys share techniques and information (even if it’s stupid bragging w1th a l0t 0f w31rd wr1t1ng); now it’s our turn to take charge and figure out what works. This isn’t just a random blog poll; your answers could affect a major research project. Updated : There’s a bug in the polling software when I embed it in a post, so please vote over on the sidebar until I figure it out. Share:

Today, in cooperation with SANS, Securosis is releasing Understanding and Selecting a Data Loss Prevention Solution. This is a compilation of my 7 part series on DLP, fully edited with expanded content, just like one of those DVD boxed sets! The paper is sponsored by Websense, but all content was developed independently by me and reviewed by SANS. It is available here, and will soon be available in the SANS Reading Room or directly from Websebse. It was a fair bit of work and I hope you like it. The content is copyrighted under a Creative Commons license, so feel free to share it and even cut out any helpful bits and pieces as long as you attribute the source. As always, questions, comments, and complaints are welcome… Share:

On Monday I’m giving a presentation on data breaches at the SANS Encryption Summit (only a couple of hours after I keynote the DLP Summit). I decided to have a little fun, and created a Star Wars opening crawl listing every public data breach in the Attrition.org database since 2000. Needless to say, it gets a little more crowded after 2005 (when people started reporting under California S.B. 1386, even though it went into effect in July of 2003). It’s over 6 minutes long, which even George Lucas wouldn’t subject an audience to. And if you’re down at the event, drop me a line… Share: