Research

Now that you’ve figured out what information you want to protect, it’s time to figure out how to protect it. In this step we’ll figure out your high-level monitoring and enforcement requirements. Determine Monitoring/Alerting Requirements Start by figuring out where you want to monitor your information: which network channels, storage platforms, and endpoint functions. Your high-level options are: Network Email Webmail HTTP/FTP HTTPS IM/Messaging Generic TCP/IP Storage File Shares Document Management Systems Databases Endpoint Local Storage Portable Storage Network Communications Cut/Paste Print/Fax Screenshots Application Control You might have some additional requirements, but these are the most common ones we encounter. Determine Enforcement Requirements As we’ve discussed in other posts, most DLP tools include various enforcement actions, which tend to vary by channel/platform. The most basic enforcement option is “Block” – the activity is stopped when a policy violation is detected. For example, an email will be filtered, a file not transferred to a USB drive, or an HTTP URL will fail. But most products also include other options, such as: Encrypt: Encrypt the file or email before allowing it to be sent/stored. Quarantine: Move the email or file into a quarantine queue for approval. Shadow: Allow a file to be moved to USB storage, but send a protected copy to the DLP server for later analysis. Justify: Warn the user that this action may violate policy, and require them to enter a business justification to store with the incident alert on the DLP server. Change rights: Add or change Digital Rights Management on the file. Change permissions: Alter the file permissions. Map Content Analysis Techniques to Monitoring/Protection Requirements DLP products vary in which policies they can enforce on which locations, channels, and platforms. Most often we see limitations on the types or size of policies that can be enforced on an endpoint, which change based as the endpoint moves off or onto the corporate network, because some require communication with the central DLP server. For the final step in this part of the process, list your content analysis requirements for each monitoring/protection requirement you just defined. These tables directly translate to the RFP requirements that are at the core of most DLP projects: what you want to protect, where you need to protect it, and how. Share:

In our last post we kicked off the DLP selection process by putting the team together. Once you have them in place, it’s time to figure out which information you want to protect. This is extremely important, as it defines which content analysis techniques you require, which is at the core of DLP functionality. This multistep process starts with figuring out your data priorities and ends with your content analysis requirements: Stack rank your data protection priorities The first step is to list our which major categories of data/content/information you want to protect. While it’s important to be specific enough for planning purposes, it’s okay to stay fairly high-level. Definitions such as “PCI data”, “engineering plans”, and “customer lists” are good. Overly general categories like “corporate sensitive data” and “classified material” are insufficient – too generic, and they cannot be mapped to specific data types. This list must be prioritized; one good way of developing the ranking is to pull the business unit representatives together and force them to sort and agree to the priorities, rather than having someone who isn’t directly responsible (such as IT or security) determine the ranking. Define the data type For each category of content listed in the first step, define the data type, so you can map it to your content analysis requirements: Structured or patterned data is content like credit card numbers, Social Security Numbers, and account numbers – that follows a defined pattern we can test against. Known text is unstructured content, typically found in documents, where we know the source and want to protect that specific information. Examples are engineering plans, source code, corporate financials, and customer lists. Images and binaries are non-text files such as music, video, photos, and compiled application code. Conceptual text is information that doesn’t come from an authoritative source like a document repository but may contain certain keywords, phrases, or language patterns. This is pretty broad but some examples are insider trading, job seeking, and sexual harassment. Match data types to required content analysis techniques Using the flowchart below, determine required content analysis techniques based on data types and other environmental factors, such as the existence of authoritative sources. This chart doesn’t account for every possibility but is a good starting point and should define the high-level requirements for a majority of situations. Determine additional requirements Depending on the content analysis technique there may be additional requirements, such as support for specific database platforms and document management systems. If you are considering database fingerprinting, also determine whether you can work against live data in a production system, or will rely on data extracts (database dumps to reduce performance overhead on the production system). Define rollout phases While we haven’t yet defined formal project phases, you should have an idea early on whether a data protection requirement is immediate or something you can roll out later in the project. One reason for including this is that many DLP projects are initiated based on some sort of breach or compliance deficiency relating to only a single data type. This could lead to selecting a product based only on that requirement, which might entail problematic limitations down the road as you expand your deployment to protect other kinds of content. Share:

As I mentioned previously, I’m working on an update to Understanding and Selecting a DLP Solution. While much of the paper still stands, one area I’m adding a bunch of content to is the selection process. I decided to buff it up with more details, and also put together a selection worksheet to help people figure out their requirements. This isn’t an RFP, but a checklist to help you figure out major requirements – which you will use to build your RFP – and manage the selection process. The first step, and this post, are fairly short and simple: Define the Selection Team Identify business units that need to be involved and create a selection committee. We tend to include two kinds of business units in the DLP selection process: content owners with sensitive data to protect, and content protectors with responsibility for enforcing controls over the data. Content owners include business units that hold and use the data. Content protectors tend to include departments like Human Resources, IT Security, Corporate Legal, Compliance, and Risk Management. Once you identify the major stakeholders you’ll want to bring them together for the next few steps. This list covers a superset of the people who tend to be involved with selection (BU stands for “Business Unit”). Depending on the size of your organization you may need more or less, and in most cases the primary selection work will be done by 2-3 IT and IT security staff, but we suggest you include this larger list in the initial requirements generation process. The members of this team will also help obtain sample data/content for content analysis testing, and provide feedback on user interfaces and workflow if they will eventually be users of the product. Share:

Back when I started Securosis my first white paper was Understanding and Selecting a DLP Solution. It has been downloaded many thousands of times (about 400 times a month for the first couple years), and I still see it showing up all the time when I talk with clients. (Some people call it the DLP Bible, but if I said that it would be really pretentious). Although the paper is still accurate, it’s time for an update. Over the next month I’ll be putting together the new revision of the paper and I want to make sure it reflects what you all need. My plans right now are to: Update the technology details. While there haven’t been any major shifts, we’ve definitely seen some useful new features and functions to consider when looking for a tool. Update the section on DLP as a Feature. The current paper focuses almost completely on full-suite solutions. While that’s still the option I usually recommend, I know some of you are only looking for coverage in a particular area. I plan to add a new section so you understand how the single channel or DLP features of other security tools work. Updated selection process. This is where I plan on putting most of myt effort… I’ll be creating a decision tree to help you prioritize your process. This section will also be released as a worksheet you can use during your selection process. It won’t name solutions, but will walk you through, and help you figure out your priorities and how those translate to technology decisions. Prettier pictures. But these are just my early ideas. If you have anything specific you want covered, feedback on the first version of the paper, or any other feedback on DLP, please let me know. You can drop it in the comments here or email me directly at rmogull@securosis.com. Also, although I’ll still follow our Totally Transparent Research process, it doesn’t make sense to post copy edits and tweaks as blog posts. I’ll post new sections and some major edits, but you’ll have to read the paper for the rest. Share:

This is one of those posts I’ve been thinking about writing for a while – ever since I saw one of those dumb-ass ADT commercials with the guy with the black knit cap breaking in through the front door while some ‘helpless’ woman was in the kitchen. I’m definitely no home-alarm security expert, but being a geek I really dug into the design and technology when I purchased systems for the two homes I’ve lived in here in Phoenix. We’re in a nice area, but home break-ins are a bit more common here than in Boulder. In one home I added an aftermarket system, and in the other we had it wired as the house was built. Here are some things to keep in mind: If you purchase an aftermarket system it will almost always be wireless, unless you want to rip your walls open. These systems can be attacked via timing and jamming, but most people don’t need to worry about that. With a wireless system you have a visible box on each door and window covered. An attacker can almost always see these, so make sure you don’t skip any. Standard door and window sensors are magnetic contact closure sensors. They only trigger if the magnet and the sensor are separated, which means they won’t detect the bad guy breaking the glass if the sensor doesn’t separate. You know, like they show in all those commercials (for the record I use ADT). The same is true for wired sensors, except they aren’t as visible. Unless you pay extra, all systems use your existing phone line with a special “capture” port that overrides other calls when the alarm needs it. For (possibly a lot) more you can get a dedicated cell phone line integrated into the alarm, so the call center still gets the alarm even if the phone lines are down. You probably want to make sure they aren’t on AT&T. Most of the cheap alarm deals only give you a certain number of contact closure sensors and one “pet immune” motion sensor (placed centrally to trigger when someone walks down your major connecting hallway). Pay more to get all your first floor doors and windows covered. Get used to the ugly white boxes on everything. Most alarm systems do not cover your exterior garage doors. The standard install protocol is to put a sensor on the door from your garage to the interior of the house. The only time we’ve been robbed is when we left our garage doors open, so since then we’ve always had them added to the system. They take a special contact closure sensor since the normal ones aren’t good with the standard rattling of a garage door and will trigger with the wind. Now every night when we set our alarm in “Stay” mode it won’t enable unless the doors are closed. None of the basic systems includes a glass break detector. Most of these are noise sensors tuned to the frequency of glass breaking, rather than shatter sensors attached to each window. I highly suggest these and recommend you put them near the windows most likely to be broken into (ones hard to see from the street). Mine has only gone off once, when I dropped something down the stairs. Understand which sensors are active in the two primary alarm modes – Stay and Away. Stay is the mode you use at night when you are sleeping (or if you are a helpless female in the kitchen in an ADT commercial). It usually arms the exterior sensors but not the motion sensor. Away is when you are out and turns on everything. I suggest having glass breaks active in Stay mode, but if you have a killer stereo/surround sound system that might not work out too well for you. There are also differences in arming times and disarming windows (the time from opening a door to entering your code). When your alarm triggers it starts a call to the call center, who will call you back and then call the police. I’ve had my alarm going for a good 30 seconds without the outbound call hitting the alarm center. It isn’t like TV, and the cops won’t be showing up right away. Most basic systems don’t cover the second story in a multilevel home. While few bad guys will use a ladder, know your home and if there are areas they can climb to easily using trees, gutters, etc. – such as windows over a low roof. Make sure you alarm these. Especially if you have daughters and want some control over their dating lives. Most systems come with key fob remotes, so you don’t have to mess with the panel when you are going in and out. If you’re one of those people who parks in your driveway and leaves your garage and alarm remotes in the car, please send me your address and a list of your valuables. Extra points if you’re a Foursquare user. Most alarms don’t come with a smoke detector, which is one of the most valuable components of the system. You regular detectors aren’t wired into an alarm sensor and are just to wake you up. Since we have pets, and mostly like them, we have a smoke detector in a central location as part of our alarm so the fire department will show up even if we aren’t around. We also have a residential sprinkler system, and as a former firefighter those things are FTW (no known deaths due to fire when one is installed and operational). My alarm guys looked at me funny when I designed the system since it included extras they normally skip (garage doors, glass break, second story coverage, smoke detector). But we have a system that didn’t cost much more than the usual cheap ones, and provides much better protection. It’s also more useful, especially with the garage sensors to help make sure we don’t leave the doors open.

My original plan for this week’s summary was to geek out a bit and talk about my home automation setup. Including the time I recently discovered that even household electrical is powerful enough to arc weld your wire strippers if you aren’t too careful. Then I read some stuff. Some really bad stuff. First up was an article in USA Today that I won’t even dignify with a link. It was on the iTunes account phishing that’s been going on, and it was pretty poorly written. Here’s a hint – if you are reading an article about a security issue and all the quotes are from a particular category of vendor, and the conclusion is to buy products made by those vendors, it’s okay to be a little skeptical. This is the second time in the past couple weeks I’ve read something by that author that suffered from the same problem. Vendor folk make fine sources – I have plenty of friends and contacts in different security companies who help me out when I need it, but the job of a journalist is to filter and balance. At least it used to be. Next up are the multitude of stories on the US Department of Defense getting infected in 2008 via USB drives. Notice I didn’t say “attacked”, because despite all the stories surfacing today it seems that this may not have been a deliberate act by a foreign power. The malware involved was pretty standard stuff – there is no need to attribute it to espionage. Now look, I don’t have any insider knowledge and maybe it was one of those cute Russian spies we deported, but this isn’t the first time we’ve seen government related stories coming from sources that might – just might – be seeking increased budget or authority. I’m really tired of a lazy press that single-sources stories and fails to actually research the issues. I know the pressure is nasty in today’s newsrooms, but there has to be a line someplace. I write for a living myself, and have some close friends in the trade press I respect a heck of a lot, so I know it’s possible to hit deadlines without sacrificing quality. But then you don’t get to put “Apple” in the title of every article to increase your page count. On another note it seems my wife is supposed to have a baby today… or sometime in the next week or two. Some of you may have noticed my posting rate is down and I’ll be in paternity leave mode. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich and Chris Hoff at RSA 2009. Video of their presentation on disruptive innovation and cloud computing. Rich quoted in Bloomberg on the Intel/McAfee deal. And also over at Forbes. Favorite Securosis Posts David Mortman: Backtalk Doublespeak on Encryption. Adrian Lane: Understanding and Selecting SIEM/Log Management. … of course. Granted it’s long, but if you are selecting a SIEM platform, this is a great primer to start the process. Mike Rothman: Data Encryption for PCI 101: Encryption Options. Really like this series because too many folks think encryption is the answer. This series tells you the question. Other Securosis Posts Starting the Understanding and Selecting an Enterprise Firewall Project. Incite 8/25/2010: Let Freedom Ring. Webcasts on Endpoint Security Fundamentals. Favorite Outside Posts David Mortman: Hoff’s 5 Rules Of Cloud Security…. Adrian Lane: Hoff’s 5 Rules Of Cloud Security…. I read this after I saw Rich’s link in this week’s Incite … and Chris has nailed it. How many of us have actually tried to set up a secure environment within Amazon Web Services? Great post. Mike Rothman: Why the USP for Every Technical Product Sounds the Same. If you think it’s hard to tell one product from another, it’s not you. This is why. And it’s sad, but really really true. Rich: Find Evil and Solve Crime. The Mandiant folks are some of the few that really fight the APT, and one of their folks is starting a series giving some insight into their process. Project Quant Posts NSO Quant: Manage IDS/IPS Process Revisited. NSO Quant: Manage IDS/IPS – Monitor Issues/Tune. Research Reports and Presentations White Paper: Understanding and Selecting SIEM/Log Management. White Paper: Endpoint Security Fundamentals. Understanding and Selecting a Database Encryption or Tokenization Solution. Top News and Posts Adobe Patches via Brian Krebs. Apple Mac OS X Security Patch. Visa Makes AppSec Recommendations. We’ll have more to say about this when we get a chance to finish reading the recommendations. Verizon Clears Credit Card Cloud Test. Yippee. Credit Cards in the cloud. And our profession needed a new place to hack credit cards to create a boost of excitement (just kidding, guys). Hey, watch where you stick that thing. You don’t know where it’s been! Researcher Arrested for Disclosure. This case is interesting for a couple different reasons. DEFCON Survey Results. Toolkit for DLL hijacking. Critical Updates for Windows, Flash Player. Apple Jailbreak Vuln. Wireshark review. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes to Jay, in response to Backtalk Doublespeak on Encryption. I don’t want to give this article too much attention, too much FUD, too few facts, but I thought this was worth a quote: “…the bad guys do not attack encrypted data directly…” which is followed up with: “When you encrypt a small field with a limited number of possible values, like the expiry date, you risk giving a determined (and sophisticated) attacker a potential route to compromising your entire cardholder database.” … by attacking the encrypted data directly? The other point I had was that there are 1 of 2 ways to create the same output given the same input (in “strong” symmetric ciphers), use ECB mode or re-use the same initialization vector (IV) over and over. I think most financial places lean towards the former because managing/transferring the

A few moments ago Mike posted his take on the McAfee/Intel acquisition, and for the most part I agree with him. “For the most part” is my nice way of saying I think Mike nailed the surface but missed some of the depths. Despite what they try to teach you in business school (not that I went to one), acquisitions, even among Very Big Companies, don’t always make sense. Often they are as much about emotion and groupthink as logic. Looking at Intel and McAfee I can see a way this deal makes sense, but I see some obstacles to making this work, and suspect they will materially reduce the value Intel can realize from this acquisition. Intel wants to acquire McAfee for three primary reasons: The name: Yes, they could have bought some dinky startup or even a mid-sized firm for a fraction of what they paid for McAfee, but no one would know who they were. Within the security world there are a handful or two of household names; but when you span government, business, and consumers the only names are the guys that sell the most cardboard boxes at Costco and Wal-Mart: Synamtec and McAfee. If they want to market themselves as having a secure platform to the widest audience possible, only those two names bring instant recognition and trust. It doesn’t even matter what the product does. Trust me, RSA wouldn’t have gotten nearly the valuation they did in the EMC deal if it weren’t for the brand name and its penetration among enterprise buyers. And keep in mind that the US federal government basically only runs McAfee and Symantec on endpoints… which is, I suspect, another important factor. If you want to break into the soda game and have the cash, you buy Coke or Pepsi – not Shasta. Virtualization and cloud computing: There are some very significant long term issues with assuring the security of the hardware/software interface in cloud computing. Q: How can you secure and monitor a hypervisor with other software running on the same hardware? A: You can’t. How do you know your VM is even booting within a trusted environment? Intel has been working on these problems for years and announced partnerships years ago with McAfee, Symantec, and other security vendors. Now Intel can sell their chips and boards with a McAfee logo on them – but customers were always going to get the tools, so it’s not clear the deal really provides value here. Mobile computing: Meaning mobile phones, not laptops. There are billions more of these devices in the world than general purpose computers, and opportunities to embed more security into the platforms. Now here’s why I don’t think Intel will ever see the full value they hope for: Symantec, EMC/RSA, and other security vendors will fight this tooth and nail. They need assurances that they will have the same access to platforms from the biggest chipmaker on the planet. A lot of tech lawyers are about to get new BMWs. Maybe even a Tesla or two in eco-conscious states. If they have to keep the platform open to competitors (and they will), then bundling is limited and will be closely monitored by the competition and governments – this isn’t only a U.S. issue. On the mobile side, as Andrew Jaquith explained so well, Apple/RIM/Microsoft control the platform and the security, not chipmakers. McAfee will still be the third party on those platforms, selling software, but consumers won’t be looking for the little logo on the phone if they either think it’s secure, it comes with a yellow logo, or they know they can install whatever they want later. There’s one final angle I’m not as sure about – systems management. Maybe Intel really does want to get into the software game and increase revenue. Certainly McAfee E-Policy Orchestrator is capable of growing past security and into general management. The “green PC” language in their release and call hints in that direction, but I’m just not sure how much of a factor it is. The major value in this deal is that Intel just branded themselves a security company across all market segments – consumer, government, and corporate. But in terms of increasing sales or grabbing full control over platform security (which would enable them to charge a premium), I don’t think this will work out. The good news is that while I don’t think Intell will see the returns they want, I also don’t think this will hurt customers. Much of the integration was in process already (as it is with other McAfee competitors), and McAfee will probably otherwise run independently. Unlike a small vendor, they are big enough and differentiated enough from the rest of Intel to survive. Probably. Share:

In our ongoing quest for world domination, we are excited to announce our formal partnership with our friends over at Liquidmatrix. Beginning immediately Dave Lewis (@gattaca) and James Arlen (@myrcurial) are joining the staff as Contributing Analysts. Dave and James will be contributing to the Securosis blog and taking part in some of our research and analysis projects. If you want to ask them questions or just say “Hi,” aside from their normal emails you can now reach them at dlewis and jarlen at securosis.com. Within the next few days we will also start providing the Liquidmatrix Security Briefing through the Securosis RSS feed and email distribution list (for those of you on our Daily Digest list). We will just be providing the Briefing – Dave, James, and their other contributors will continue to blog on other issues at [the Liquidmatrix site(http://www.liquidmatrix.org/blog/). But you’ll also start seeing new content from them here at Securosis as they participate in our research projects. We’re biased but we think this is a great partnership. Aside from gaining two more really smart guys with a lot of security experience, this also increases our ability to keep all of you up to date on the latest security news. I’d call it a “win-win”, but I think they’ll figure out soon enough that Securosis is the one gaining the most here. (Don’t worry, per SOP we locked them into oppressive ironclad contracts). Dave and James now join David Mortman and Gunnar Peterson in our Contributing Analyst program. Which means Mike, Adrian, and I are officially outnumbered and a bit nervous.   Share:

We are ridiculously excited to announce that Gunnar Peterson is the newest member of Securosis, joining us as a Contributing Analyst. For those who don’t remember, our Contributor program is our way of getting to work with extremely awesome people without asking them to quit their day jobs (contributors are full members of the team and covered under our existing contracts/NDAs, but aren’t full time). Gunnar joins David Mortman and officially doubles our Contributing Analyst team. Gunnar’s primary coverage areas are identity and access management, large enterprise applications, and application development. Plus anything else he wants, because he’s wicked smart. Gunnar can be reached at gpeterson at securosis.com on top of his existing emails/Skype/etc. And now for the formal bio: Gunnar Peterson is a Managing Principal at Arctec Group. He is focused on distributed systems security for large mission critical financial, financial exchange, healthcare, manufacturer, and insurance systems, as well as emerging start ups. Mr. Peterson is an internationally recognized software security expert, frequently published, an Associate Editor for IEEE Security & Privacy Journal on Building Security In, a contributor to the SEI and DHS Build Security In portal on software security, a Visiting Scientist at Carnegie Mellon Software Engineering Institute, and an in-demand speaker at security conferences. He maintains a popular information security blog at http://1raindrop.typepad.com. Share:

A couple days ago I was talking with the masters swim coach I’ve started working with (so I will, you know, drown less) and we got to that part of the relationship where I had to tell him what I do for a living. Not that I’ve ever figured out a good answer to that questions, but I muddled through. Once he found out I worked in infosec he started ranting, as most people do, about all the various spam and phishing he has to deal with. Aside from wondering why anyone would run those scams (easily answered with some numbers) he started in on how much of a pain in the ass it is to do anything online anymore. The best anecdote was asking his wife why there were problems with their Bank of America account. She gently reminded him that the account is in her name, and the odds were pretty low that B of A would be emailing him instead of her. When he asked what he should do I made sure he was on a Mac (or Windows 7), recommended some antispam filtering, and confirmed that he or his wife check their accounts daily. I’ve joked in the past that you need the equivalent of a black belt to survive on the Internet today, but I’m starting to think it isn’t a joke. The majority of my non-technical friends and family have been infected, scammed, or suffered fraud at least once. This is just anecdote, which is dangerous to draw assumptions from, but the numbers are clearly higher than people being mugged or having their homes broken into. (Yeah, false analogy – get over it). I think we only tolerate this for three reasons: Individual losses are still generally low – especially since credit cards losses to a consumer are so limited (low out of pocket). Having your computer invaded doesn’t feel as intrusive as knowing someone was rummaging through your underwear drawer. A lot of people don’t notice that someone is squatting on their computer… until the losses ring up. I figure once things really get bad enough we’ll change. And to be honest, people are a heck of a lot more informed these days than five or ten years ago. On another note we are excited to welcome Gunnar Peterson as our latest Contributing Analyst! Gunnar’s first post is the IAM entry in our week-long series on security commoditization, and it’s awesome to already have him participating in research meetings. And on yet another note it seems my wife is more than a little pregnant. Odds are I’ll be disappearing for a few weeks at some random point between now and the first week of September, so don’t be offended if I’m slow to respond to email. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences The official Defcon Security Jam waffle iron is up for auction! Not only was this used by David Mortman to produce mouth watering morsels of joy on stage, but Chris Hoff ensured the waffle iron attended the exclusive Ninja Networks party! (Proceeds benefit the EFF). Adrian on How to Protect Oracle Database Vault at Dark Reading. Rich wrote an article on iOS security over at TidBITS. Rich, Martin, and Zach on the Network Security Podcast. Favorite Securosis Posts Gunnar: Anton Chuvakin in depth SIEM Use Cases. Written from a hands on perspective, covers core SIEM workflows inlcuding Server user activity monitoring, Tracking user actions across systems, firewall monitoring (security + network), Malware protection, and Web server attack detection. The Use Cases show the basic flows and they are made more valuable by Anton’s closing comments which address how SIEM enables Incident Response activities. Adrian Lane: FireStarter: Why You Care about Security Commoditization. Maybe no one else liked it, but I did. Mike Rothman: The Yin and Yang of Security Commoditization. Love the concept of “covering” as a metaphor for vendors not solving customer problems, but trying to do just enough to beat competition. This was a great series. Rich: Gunnar’s post on the lack of commoditization in IAM. A little backstory – I was presenting my commoditization thoughts on our internal research meeting, and Gunnar was the one who pointed out that some markets never seem to reach that point… which inspired this week’s series. Other Securosis Posts Gunnar Peterson Joins Securosis as a Contributing Analyst. Incite 8/11/2010: No Goal! Tokenization: Use Cases, Part 3. iOS Security: Challenges and Opportunities. Tokenization Topic Roundup. When Writing on iOS Security, Stop Asking AV Vendors Whether Apple Should Open the Platform to AV. Commoditization and Feature Parity on the Perimeter. Tokenization: Use Cases, Part 2. Favorite Outside Posts Adrian Lane: Researchers Hack Your Vehicle (again). Looks like the auto industry will continue making idiotic decisions regarding computers and control systems until they walk head-on into a major hack. Mike Rothman: Fuel Not Powerpoint. From our newest contributing analyst Gunnar. Funny how in some industries a cool PowerPoint is not enough. Pepper: Anatomy Of An Attempted Malware Scam. I’ve never thought much about ‘badvertising’, but I enjoyed this detective story. Rich: National Geographic’s awesome story on DefCon. The reporter really captured the essence of the event. Project Quant Posts NSO Quant: Manage Firewall Process Revisited. NSO Quant: Manage Firewall – Audit/Validate. NSO Quant: Manage Firewall – Deploy. NSO Quant: Manage Firewall – Test and Approve. NSO Quant: Manage Firewall – Process Change Request. Research Reports and Presentations White Paper: Endpoint Security Fundamentals. Understanding and Selecting a Database Encryption or Tokenization Solution. Low Hanging Fruit: Quick Wins with Data Loss Prevention. Top News and Posts Critical Updates for Windows, Flash Player. Questions and Answers on the [iPhone] JailbreakMe Vulnerability. Wireshark review. RBS WorldPay ringleader being extradited to the US. Illogical cloud positivism. Google CEO says no anonymity on the web. First clue to crack the Verizon DBIR contest. Blog Comment of the Week Remember, for every comment selected, Securosis makes a $25 donation to Hackers for Charity. This week’s best comment goes