Securosis

Menu

Research

Data Security Lifecycle- Technologies, Part 3

Rich December 11, 2007 No Comments

  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.

Share:
Read Post

ipfw Rules, v2007/12/12

reppep December 11, 2007 10 Comments

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:

Share:
Read Post
dinosaur-sidebar

Research

view all

Sign Up for Our Newsletter

Totally Transparent Research is the embodiment of how we work at Securosis. It’s our core operating philosophy, our research policy, and a specific process. We initially developed it to help maintain objectivity while producing licensed research, but its benefits extend to all aspects of our business.

Going beyond Open Source Research, and a far cry from the traditional syndicated research model, we think it’s the best way to produce independent, objective, quality research.

Here’s how it works:

  • Content is developed ‘live’ on the blog. Primary research is generally released in pieces, as a series of posts, so we can digest and integrate feedback, making the end results much stronger than traditional “ivory tower” research.
  • Comments are enabled for posts. All comments are kept except for spam, personal insults of a clearly inflammatory nature, and completely off-topic content that distracts from the discussion. We welcome comments critical of the work, even if somewhat insulting to the authors. Really.
  • Anyone can comment, and no registration is required. Vendors or consultants with a relevant product or offering must properly identify themselves. While their comments won’t be deleted, the writer/moderator will “call out”, identify, and possibly ridicule vendors who fail to do so.
  • Vendors considering licensing the content are welcome to provide feedback, but it must be posted in the comments - just like everyone else. There is no back channel influence on the research findings or posts.
    Analysts must reply to comments and defend the research position, or agree to modify the content.
  • At the end of the post series, the analyst compiles the posts into a paper, presentation, or other delivery vehicle. Public comments/input factors into the research, where appropriate.
  • If the research is distributed as a paper, significant commenters/contributors are acknowledged in the opening of the report. If they did not post their real names, handles used for comments are listed. Commenters do not retain any rights to the report, but their contributions will be recognized.
  • All primary research will be released under a Creative Commons license. The current license is Non-Commercial, Attribution. The analyst, at their discretion, may add a Derivative Works or Share Alike condition.
  • Securosis primary research does not discuss specific vendors or specific products/offerings, unless used to provide context, contrast or to make a point (which is very very rare).
    Although quotes from published primary research (and published primary research only) may be used in press releases, said quotes may never mention a specific vendor, even if the vendor is mentioned in the source report. Securosis must approve any quote to appear in any vendor marketing collateral.
  • Final primary research will be posted on the blog with open comments.
  • Research will be updated periodically to reflect market realities, based on the discretion of the primary analyst. Updated research will be dated and given a version number.
    For research that cannot be developed using this model, such as complex principles or models that are unsuited for a series of blog posts, the content will be chunked up and posted at or before release of the paper to solicit public feedback, and provide an open venue for comments and criticisms.
  • In rare cases Securosis may write papers outside of the primary research agenda, but only if the end result can be non-biased and valuable to the user community to supplement industry-wide efforts or advances. A “Radically Transparent Research” process will be followed in developing these papers, where absolutely all materials are public at all stages of development, including communications (email, call notes).
    Only the free primary research released on our site can be licensed. We will not accept licensing fees on research we charge users to access.
  • All licensed research will be clearly labeled with the licensees. No licensed research will be released without indicating the sources of licensing fees. Again, there will be no back channel influence. We’re open and transparent about our revenue sources.

In essence, we develop all of our research out in the open, and not only seek public comments, but keep those comments indefinitely as a record of the research creation process. If you believe we are biased or not doing our homework, you can call us out on it and it will be there in the record. Our philosophy involves cracking open the research process, and using our readers to eliminate bias and enhance the quality of the work.

On the back end, here’s how we handle this approach with licensees:

  • Licensees may propose paper topics. The topic may be accepted if it is consistent with the Securosis research agenda and goals, but only if it can be covered without bias and will be valuable to the end user community.
  • Analysts produce research according to their own research agendas, and may offer licensing under the same objectivity requirements.
  • The potential licensee will be provided an outline of our research positions and the potential research product so they can determine if it is likely to meet their objectives.
  • Once the licensee agrees, development of the primary research content begins, following the Totally Transparent Research process as outlined above. At this point, there is no money exchanged.
  • Upon completion of the paper, the licensee will receive a release candidate to determine whether the final result still meets their needs.
  • If the content does not meet their needs, the licensee is not required to pay, and the research will be released without licensing or with alternate licensees.
  • Licensees may host and reuse the content for the length of the license (typically one year). This includes placing the content behind a registration process, posting on white paper networks, or translation into other languages. The research will always be hosted at Securosis for free without registration.

Here is the language we currently place in our research project agreements:

“Content will be created independently of LICENSEE with no obligations for payment. Once content is complete, LICENSEE will have a 3 day review period to determine if the content meets corporate objectives. If the content is unsuitable, LICENSEE will not be obligated for any payment and Securosis is free to distribute the whitepaper without branding or with alternate licensees, and will not complete any associated webcasts for the declining LICENSEE. Content licensing, webcasts and payment are contingent on the content being acceptable to LICENSEE. This maintains objectivity while limiting the risk to LICENSEE. Securosis maintains all rights to the content and to include Securosis branding in addition to any licensee branding.”

Even this process itself is open to criticism. If you have questions or comments, you can email us or comment on the blog.