Research

It used to be that we didn’t care too much if someone stole a pile of email addresses. At worst we’d end up on yet another spam list, and these days most folks have pretty decent spam filters. Sure, it’s annoying, but it was pretty low on the scale of security risks. But I’m starting to think that email addresses – depending on context – are now worth far more to certain attackers than credit card numbers. As annoying as credit card fraud is, it’s generally a manageable problem. For us as consumers it’s mostly a nuisance, because we are protected from financial loss. It’s a bigger problem for merchants and banks, but fraud detection systems and law enforcement together manage to keep losses to an acceptable level – otherwise we would see Chip and PIN or other technologies, as opposed to PCI, as the security focus. In terms of economics, we have seen bad guys shift to lower-level persistent fraud rather than big breaches. They’re stealing a lot, but the big lesson from the Verizon Data Breach Investigations Report is that they are stealing smaller batches, and are much more likely to get caught than in the past. Your email, on the other hand, may be far more valuable. Not necessarily to random online street criminals (although it’s still valuable to them, too), but to more sophisticated attackers. At least if they get your email address with ‘interesting’ context. Let’s look at the main method of attacks these days. From APT to botnets, we see one consistent trend – reliance on phishing to get past user defenses and gain a beachhead on the target. Get the user to click a link or open a file, and you own their system. “Spear phishing” (highly targeted phishing) has been identified as the primary attack technique currently being used by the APT – they will shift once it stops working so well. Now think about last week’s breach of Sega, or back to the Epsilon breach. In these cases emails, first names, and context were obtained. Not just an email, but an email with a real name and a site you registered to receive email from. We like to hammer users on how stupid they are for clicking any link in a storm, but what are the odds of even the most seasoned security professionals defending themselves from every single one of these attacks with, in effect, detailed dossiers on the targets? When you get a correctly formatted email with your name from a site you registered with, there’s a reasonable chance you will click – and they can easily afford to send more fishing messages than real mail (spam has been up as high as 90% of email on the Internet, and these are much better at looking legitimate and getting past spam filters). Don’t play coy and claim you’ll check the From: address every time – these all come from services you don’t know personally, and often from a third party domain as part of the service. Considering everything an attacker can do with those resources, I suspect email addresses + context might be the new bad guy hotness. Hit every TiVo subscriber with a personally addressed phishing message, perhaps modeled from the last email blast TiVo actually sent out? Gold. Share:

Continuing our series on tokenization for compliance, it’s time to look at how tokens are used to secure payment data. I will focus on how tokenization is employed for credit card security and helps with compliance because this model is driving adoption today. As defined in the introduction, tokenization is the process of replacing sensitive information with tokens. The tokens are ‘random’ values that resemble the sensitive data they replace, but lack intrinsic value. In terms of payment data security, tokenization is used to replace sensitive payment data such as bank account numbers. But its recent surge in popularity has been specifically about replacing credit card data. The vast majority of current tokenization projects are squarely intended to reduce the cost of achieving PCI compliance. Removing credit cards from all or part of your environment sounds like a good security measure, and it is. After all, thieves can’t steal what’s not there. But that’s not actually why tokenization has become popular for credit card replacement. Tokenization is popular because it saves money. Large merchants must undergo extensive examinations of their IT security and processes to verify compliance with the Payment Card Industry Data Security Standard (PCI-DSS). Every system that transmits or stores credit card data is subject to review. Small and mid-sized merchants must go through all the same steps as large merchants except the compliance audit, where they are on the honor system. The list of DSS requirements is lengthy – a substantial investment of time and money is required to create policies, secure systems, and generate the reports PCI assessors need. While the Council’s prescribed security controls are conceptually simple, in practice they demand a security review of the entire IT infrastructure. Over the last couple decades firms have used credit card numbers to identify and reference customers, transactions, payments, and chargebacks. As the standard reference key, credit card numbers were stored in billing, order management, shipping, customer care, business intelligence, and even fraud detection systems. They were used to cross-reference data from third parties in order to gather intelligence on consumer buying trends. Large retail organizations typically stored credit card data in every critical business processing system. When firms began suffering data breaches they started to encrypt databases and archives, and implemented central key management systems to control access to payment data. But faulty encryption deployments, SQL injection attacks, and credential hijacking continued to expose credit cards to fraud. The Payment Card Industry quickly stepped in to require a standardized set of security measures of everyone who processes and stores credit card data. The problem is that it is incredibly expensive to audit network, platform, application, user, and data security across all these systems – and then document usage and security policies to demonstrate compliance with PCI-DSS. If credit card data is replaced with tokens, almost half of the security checks no longer apply. For example, the requirement to encrypt databases or archives goes away with credit card numbers. Key management systems shrink, as they no longer need to manage keys across the entire organization. You don’t need to mask report data, rewrite applications, or reset user authorization to restrict access. Tokenization drastically reduces the complexity and scope of auditing and securing operations. That doesn’t mean you don’t need to maintain a secure network, but the requirements are greatly reduced. Even for smaller merchants who can self-assess, tokenization reduces the workload. You must secure your systems – primarily to ensure token and payment services are not open to attack – but the burden is dramatically lightened. Tokens can be created and managed in-house, or by third party service providers. Both models support web commerce and point-of-sale environments, and integrate easily with existing systems. For in-house token platforms, you own and operate the token system, including the token database. The token server is integrated with back-end transaction systems and swaps tokens in during transactions. You still keep credit card data, but only a single copy of each card, in the secure token database. This type of systems is most common with very large merchants who need to keep the original card data and want to keep transaction fees to a minimum. Third-party token services, such as those provided directly by payment processors – return a token to signify a successful payment. But the merchant retains only the token rather than the credit card. The payment processor stores the card data along with the issued token for recurring payments and dispute resolution. Small and mid-sized merchants with no need to retain credit card numbers lean towards this model – they sacrifice some control and pay higher transaction fees in exchange for convenience, reduced liability, and compliance costs. Deployment of token systems can still be tricky, as you need to substitute existing payment data with tokens. Updates must be synchronized across multiple systems so keys and data maintain relational integrity. Token vendors, both in-house and third party service providers, offer tools and services to perform the conversion. If you have credit card data scattered throughout your company, plan on paying a bit more during the conversion. But tokenization is mostly a drop-in replacement for encryption of credit card data. It requires very little in the way of changes to your systems, processes, or applications. While encryption can provide very strong security, customers and auditors prefer tokenization because it’s simpler to implement, simpler to manage, and easier to audit. Today, tokenization of payment data is driving the market. But there are many other uses for data tokenization, particularly in health care and for other Personally Identifiable Information (PII). In the mid-term I expect to see tokenization increasingly applied to databases containing PII, which is the topic for our next post. Share:

With the news that Dropbox managed to leave every single user account wide open for four hours, it’s time to review encryption options. We are fans of Dropbox here at Securosis. We haven’t found any other tools that so effectively enable us to access our data on all our systems. I personally use two primary computers, plus an iPad and iPhone, and with my travel I really need seamless synchronization of all that content. I always knew the Dropbox folks could access my data (easy to figure out with a cursory check of their web interface code in the browser), so we have always made sure to encrypt sensitive stuff. Our really sensitive content is on a secure internal server, and Dropbox is primarily for working documents and projects – none of which are highly sensitive. That said, I’m having serious doubts about continued use of the service. It’s one thing for their staff to potentially access my data. It’s another to reveal fundamental security flaws that could expose my data to the world. It’s unacceptable, and the only way they can regain user trust is to make architectural changes and allow users to encrypt their content at the client, even if it means sacrificing some server capabilities. I wrote about some options they could implement a while ago, and if they encrypt file contents while leaving metadata unencrypted (at least as a user option), they could even keep a lot of the current web interface functionality, such as restoring deleted files. That said, here are a couple easy ways to encrypt your data until Dropbox wakes up, or someone else comes out with a secure and well-engineered alternative service. (Update: Someone suggested Spideroak as a secure alternative… time to research.) Warning!! Sharing encrypted files is a risk. It is far easier to corrupt data, especially using encrypted containers as described below. Make darn sure you only have the container/directory open on a single system at a time. Also, you cannot access files using these encryption tools from iOS or Android. Encrypted .dmg (Mac only): All Macs support encrypted disk images that mount just like an external drive when you open them and supply your password. To create one, open Disk Utility and click New Image. Save the encrypted image to Dropbox, set a maximum size, and select AES-256 encryption. The only other option to change is to use “sparse bundle disk image” as Image Format. This breaks your encrypted ‘disk’ into a series of smaller files, which means Dropbox only has to sync the changes rather than copying the whole image on every single modification. This is the method I use –. to access my file I double-click the image and enter the password, which mounts it like an external drive. When I’m done I eject it in the Finder. TrueCrypt (Mac/Windows/Linux): TrueCrypt is a great encryption tool supported by all major platforms. First, download TrueCrypt. Run TrueCrypt and select Create Volume, then “create an encrypted file container”. Follow the wizard with the defaults, placing your file in Dropbox and selecting the FAT file system if you want access to it from different operating systems. If you know what you’re doing, you can use key files instead of passwords, but either is secure enough for our purposes. Those are my top two recommendations. Although a variety of third-party encryption tools are available, even TrueCrypt is easy enough for an average user. Additionally, some products (particularly security products such as 1Password) properly encrypt anything they store in Dropbox by default. Again, be careful. Don’t ever open these containers on two systems at the same time. You might be okay, or you might lose everything. And (especially for TrueCrypt) you might want to use a few smaller containers to reduce the data sync overhead. Dropbox attempts to only synchronize deltas, but encryption can break this, meaning even a small change may require a recopy of the entire container to or from every Dropbox client. And Dropbox may only detect changes when you close the encrypted container, which flushes all changes to the file. I really love how well Dropbox works, but this latest fumble shows the service can’t be trusted with anything sensitive. If their response to this exposure is to improve processes instead of hardening the technology, that will demonstrate a fundamental misunderstanding of the security needs of customers. The alarm went off – let’s see if they hit the snooze button. Share:

Where would you invest? The Reuters article about Silicon Valley VCs betting on new technologies to protect computer networks got me thinking about where I would invest in computer security. This is a very tough question, because where I would invest in security technologies as a CIO is different than where I would invest as a venture capitalist. I can see security bets to address most CIOs’ need to spend money, or and quite different technologies address noisy threats, which could make investors money. As Gunnar pointed out in Unfrozen Caveman Attacker (my favorite post this week) firewalls, anti-virus, and anti-malware are SSDD – but clearly people are buying plenty of it. As long as we are playing with Monopoly money, as a CIO facing today’s threats I would invest in the following areas (regardless of business type): Endpoint encryption – the easiest-to-use products I could find – to protect USB sticks, laptops, mobile and cloud data. As little as possible in ‘content’ security for email and web to slow down spam, phishing, and malware. Browser security to thwart drive-by attacks. Application layer monitoring both for specific applications like web apps and databases, alongside generic application controls and monitoring for approved applications. And (probably) file integrity monitoring tools. A logging service. Identity, Access, and Authorization management systems – the basis for determining what users are allowed access and what they can do. From there it’s all about effective deployment of these technologies, with small shifts in focus to fit specific business requirements. Note that I am ignoring compliance considerations, just thinking about data and system security. But as a VC, I would invest in what I think will sell. And I can sell lots of things: “Next Generation Firewalls” Cloud and virtual security products – whatever that may be. WAF. Anti-Virus, in response to the pervasive fear of system takeover – despite its lack of effectiveness for detection or removal. Anti-malware – with the escalating number of attacks in the news, this another easy sell. Anything under the label “Mobile Security”. Finally, anything compliance related: technologies that help people quickly achieve compliance with some aspect of PCI, HITECH or some portion of a requirement. Quick sales growth is about addressing visible customer pain points – real or perceived. It’s not about selling snake oil – it’s about quick wins and whatever customers demand. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted on Chinese hacking. Rich discusses Cloud Security. Rich on LulzSec at BoingBoing. Favorite Securosis Posts Adrian Lane: Truth and (Dis)Information. Mike Rothman: Secure Passwords Sans Sales Pitch. The antidote for brute force is: a password manager. Other Securosis Posts The Hazards of Generic Communications. Stop Asking for Crap You Don’t Need and Won’t Use. Incite 6/15/2011: Shortcut to Hypocrisy. More Control Doesn’t Equal More Secure. Balancing the Short & Long Term. Favorite Outside Posts Adrian Lane: Unfrozen Caveman Attacker. Moog like SQL injection! SQL injection WORK! Mike Rothman: Asymmetry of People’s Time in Security Incidents. Lenny points out why it’s hard to be a security professional. We have more to cover and have to expend exponentially more resources than the bad guys. And this asymmetry goes way beyond incident response. Project Quant Posts DB Quant: Index. NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. Research Reports and Presentations Understanding and Selecting a File Activity Monitoring Solution. Database Activity Monitoring: Software vs. Appliance. React Faster and Better: New Approaches for Advanced Incident Response. Measuring and Optimizing Database Security Operations (DBQuant). Top News and Posts Use of Exploit Kits on the Rise Why? Because they work. And because you can create hacks quickly. Sound like a good productivity app? Big Blue at 100. Citi Credit Card Hack Bigger Than Originally Disclosed. Apparently the vulnerability was to simple URL substitution – you know, randomly editing the credit card number or user ID. Shocking if true! Adobe’s Quarterly Patch Update. 34 Security Flaws Patched (Microsoft). New PCI Guidance around Virtualization (PDF). Rich and Adrian will post analysis of this next week. EU Wants to Criminalize Hacking Tools. D’oh! Lulz DDoS on CIA.gov. Beaker vMotioned. Projector Passwords? Valid point about security prohibiting you from doing your job, and more evidence that Sony is focused on the wrong threats and shooting itself in the foot as a result. More Malicious Android Apps. 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 kurk wismer, in response to FireStarter: Trust and (Dis)Information. you’re not nuts. telling your opponent how you intend to attack them, thereby giving them an opportunity to deploy countermeasures, would be a great way to cause your strategy to fail. even in the unlikely event that the authorities believe they’ve already gotten all the information they need out of these informants, there are always new actors entering the arena that the informants could have been useful against if their existence hadn’t been given away. the only way this makes sense for an intelligent actor is if the claim about informants is psyops, as you suggest. unfortunately, i don’t think we can’t assume the authorities are that intelligent. it would certainly be nice if they were, but high-level stupidity is not unheard of. Share:

Ever since I wrote the Pragmatic CSO a lifetime ago (okay, 4 years, but it feels like a lifetime), I have been evangelizing about better quantification of security programs. Even without context, quantification is valuable, but they are much more useful together. So I have been pushing hard for finding a set of similar companies to compare your metrics against, to provide that needed context. Alas, with the number of fires we have to fight every day, most security folks just don’t make the time to embrace metrics. This paper focuses on why you should. We consider security metrics at a high level to lay the foundation, then spend most of the paper explaining what benchmarking offers your security program and how to do it. A brief excerpt from the Executive Summary explains it well: A key aspect of maturing our security programs must be the collection of security metrics and their use to improve operational processes. Even those with broad security metrics programs still have trouble communicating the relative effectiveness of their efforts – largely because they have no point of comparison. Thus when talking about the success/failure of any security program, without an objective reference point senior management has no idea if your results are good. Or bad. Enter the Security Benchmark, which involves comparing your security metrics to a peer group of similar companies. If you can get a fairly broad set of consistent data (both quantitative and qualitative), then compare your numbers to that dataset, you can get a feel for relative performance. Obviously this is very sensitive data, so due care must be exercised when sharing it, but the ability to transcend the current and arbitrary identification of problem areas as ‘red’ (bad), ‘yellow’ (not so bad), or ‘green’ (a bit better) enables us to finally have some clarity on the effectiveness of our security programs. Additionally, the metrics and benchmark data can be harnessed internally to provide objectives and illuminate trends to improve key security operations. Those of you who embrace quantification gain an objective method for making decisions about your security program. No more black magic, voodoo, or hypnosis to get your budget approved, okay? The paper has a landing page, or you can download the paper directly: Security Benchmarking: Going Beyond Metrics (PDF). While you are enjoying the paper, please send a thank you to nCircle for licensing it. Share:

Rich, Adrian, and I are pretty lucky. We are bombarded by data coming at us from every direction. What’s working, what’s not, who’s attacking who, what new widgets are out there – and that’s just the tip of the iceberg. For an information junkie like me, it’s a sort of nirvana. But absorbing all this information without being able to relay it to folks who need it defeats the purpose. Success in an analyst role comes down to talking to folks at the level and in the language that they need, to digest and use whatever you are telling them. I would expand the scope of that idea: being able to communicate is a critical success factor for any role. As I mentioned in my recent Dark Reading post (The Truth Will Set You Free), as an industry we aren’t very good at communicating, and this is a big problem as security gets a higher profile. Far too many folks make generic statements about threats and controls, assuming their own perspectives work for everyone. Lonervamp points this out in the cold, harsh light of reality by dismantling a recent post on McAfee’s blog in smb security advice: don’t read this article. McAfee’s post allegedly targeted an SMB audience with Five Simple Steps SMBs Can Take to Avoid a Disastrous Data Breach. But its language and guidance were more appropriate to an enterprise reader. LV did a great job discussing why each of their 5 steps were really ridiculous, given SMBs’ general lack of sophistication. Yes, that is another generalization, but it is generally correct in my experience. I’ll cut McAfee some slack because this came from their risk/compliance group – and they’re not really selling anything an SMB would buy. But that’s just one of about a zillion examples of how we screw up communications. This is vendor to customer communication, but both security folks talking to their organization (at both high and low levels), and consultants talking to customers, suffer from the same tone-deaf approach of figuring a single message works for everyone. It doesn’t. I should know – I have screwed this up countless times in pretty much every role I’ve ever had. So at least I have a few ideas about how to do it better. I’m particularly sensitive to this because we are starting to spend many more cycles on Securosis’ SMB-targeted offering. It literally requires us to shut down the enterprise part of our brains (which the three of us have honed for years) and think like an SMB. At the end of the day a little reminder can make a world of difference: it’s about understanding your audience. Really? Yes, it’s that simple. But still very difficult in practice. Which is why it’s important to sprinkle in industry vernacular if you are talking to a certain industry group. Why you need to focus on business-centric issues and outcomes if you speak to senior management. And why you need to keep things simple if you are addressing a group of small business people. Again, if you are in an SMB, or you are a senior manager, or you work in a certain industry: please don’t take offense. I’m not saying you can’t understand generic language. My point is that you shouldn’t have to. Any person communicating with you should respect you and your time enough to make sure their information is relevant to you, and to consider their presentation rather than merely repeating what they say to everyone else. Share:

I recently had a conversation with a vendor about a particular feature in their product: Me: “So you just added XZY to the product?” Them: “Yep.” Me: “You know that no one uses it.” Them: “Yep.” Me: “But it’s on all the RFPs, isn’t it?” Them: “Yep.” I hear this scenario time and time again. Users ask for features they will never really use in RFPs, simply because they saw it on a competitor’s marketing brochure, or because “it sounds like it could be cool.” The vendors are then forced to either build it in, or just have their sales folks lie about it (it isn’t like you’ll notice). And then users complain about how bloated the products are. This is a vicious, abusive loop of a relationship. It usually starts when one VERY LARGE client asks for something (which they may or may not use), or a VERY LARGE potential partner asks for some interoperability. It never works right because no one really tests it outside the lab, and almost no one uses it anyway. But it’s on every damn RFP so all the other vendors sigh in frustration and mock up their own versions. My favorite is DLP/DRM integration. Sure, I’m a firm believer that someday it will be extremely useful. But right now? A bunch of management dudes are throwing it into every RFP, probably after reading something from Jericho, and I’m not sure I know of a single production deployment. Tired of bloat in your products? Ask for what you need and then buy it. Stop building RFPs with cut and paste. Don’t order the 7 course meal when you only want PB&J. A nice, fulfilling, yummy PB&J that gets the job done. (No, this doesn’t excuse vendors when the important stuff doesn’t work, but seriously… if you’re going to bitch about bloat, stop demanding it!) Share:

I’m not a big basketball fan. I like the NCAA tournament. I may watch a game or two of the NBA playoffs/finals, but I don’t follow them. It seems nothing can get our nation to rise up like a common enemy. That enemy was the Miami Heat. My Tweeter exploded last night with all sorts of venom against the Heat, as they were losing to the Mavs. I could only laugh. Because it was a great example of the hypocrisy of so many sports fans. The Heat draws the ire of basically everyone because the top 3 free agents last year decided to play in Miami. The big 3 each took a $10-20MM financial hit in order to win championships. Sure, I see how fans of other teams can feel put out. Especially the fans in Cleveland who ended up holding the bag when LeBron left. But folks in LA? Folks in Boston? Folks in NYC? C’mon, man! How is what those teams do any different than what the Heat did? Except maybe the Heat did a better job – they landed the free agent whales. It seems like Boston fans have managed to forget Danny Ainge betting the ranch to bring in Kevin Garnett and Ray Allen to join Paul Pierce. And they delivered a championship. But that was different, right, Celtics fans? The Knicks signed A’mare and then traded pretty much everything else to get Carmelo Anthony. How is that different, especially after a first round exit in the playoffs? They talk about short cuts and in some of these pro leagues an owner willing to bet the ranch can assemble a very competitive team right now. How about baseball? The Yankees and Red Sox have been doing this forever. The Phillies joined the club this year as well, paying through the nose for Cliff Lee. And would it surprise anyone to see these teams playing in late October? What’s more surprising was last year, when teams like San Francisco and Texas got to play in the World Series. That gets my the point: folks are really pissed merely because their teams couldn’t get those guys. Basically they are jealous and complaining someone else did a better job – hypocrites. Maybe the sorest guy about this whole thing is the dude that owns the Cavs – Dan Gilbert. He was kind enough to tweet about the fact there are no shortcuts, which is a load of crap. There may not be a shortcut directly to winning the championship, but there are certainly shortcuts to make a team very competitive. And if you aren’t competitive, I’m pretty sure you won’t be playing in the championship. Photo credits: “Hypocrisy” originally uploaded by satosphere Incite 4 U On the “budget less” CISO: Raf Los seems to be hell-bent on antagonizing pretty much every CISO out there, advocating a divorce of the CISO from the security budget. The thing is, he’s advocating taking away something that was never really there in the first place. Sure, every company (of scale anyway) has a security budget, but that’s not our money. That’s the money the business has allocated as a cost of doing business. Maybe it’s to meet compliance needs. Maybe it’s to provide a minimum level of security. You can be sure the CFO will be trying to minimize this cost. Raf talks about a very Pragmatic approach to working with the business, in order to get them ultimately to buy into better controls. I have long believed that persuasion is the CISO’s most important skill – you must make the case to protect against an unknown attacker, using an unknown attack, going after data that may or may not be important. – MR ePayment pie: The fight for mobile payment supremacy is in full swing. And why not? Person to person commerce – with every mobile device able to be a point of sale terminal – offers huge potential revenue. The credit card providers love the concept of Square and Mophie Marketplace. It’s a win-win – for the banks anyway. Not only does more money move through the credit card system, but it gets close to removing cash from commerce altogether by making credit and pre-pay cards the de facto currency, with 2-3% transaction fees. Tons of smaller virtual currency providers are popping up to support people who want to pay in different ways, for everything from social networking to porn. You know it’s a big deal when the political lobbyists are going after other forms of virtual currency – like Bitcoin and Live Gamer – positioning their competition as unstable and only for online gaming and buying illegal drugs. Each virtual currency has its ideal application, and each has benefits for security, privacy, anonymity, and/or financial protection. So we will see plenty of FUD as all the players fight for a bigger slice of the revenue. – AL Passwords still suck: No, not the actual concept of passwords. Those are fine, as Adrian points out when pushing password managers. But only if you use them. The LulzSec folks continue to wreak havoc, so we might as well learn something from them. Troy Hunt does a great analysis of the passwords posted as a result of one Sony breach. Lots of pie charts and even a comparison to the file of Gawker passwords posted last year. The results are predictable, and sad. Well, they are sad if you want to improve the world. You can be happy if you are just hoping to not get pwned personally. Given the sheer number of weak passwords out there, if you use something a little less weak, you have a good chance of being over the threshold of what’s worthwhile for the bad guys. And lord knows, they are still all about the path of least resistance. – MR Zero knowledge pulpit: There is absolutely no reason to believe you can’t securely house PCI data in a cloud or virtualized environment. Ellen Messmer’s article questioning

Last week, while teaching the CCSK (cloud security) class, the discussion reached a point I often find myself in these days. We were discussing the risk of cloud computing, and one of the students listed “less control” as a security risk. To be honest, this weaves itself through not only the Guidance but most risk analyses I have seen. And it’s not limited to cloud discussions. One of the places I hear it most often is in reference to mobile computing – especially iOS devices. For example, while hosting an event at RSA earlier this year we had a security pro with over 10 years experience state that they don’t let iPads/iPhones in, but they still use Windows XP. When I asked why they allow a patently out of date and insecure OS, while blocking one of the most secure devices on the market, his response was “we know Windows XP and can control it”. Which, to me, is like saying you are satisfied to pick exactly which window the burglar will come and leave through. More knowledge or control doesn’t necessarily translate into better security. In fact, uncertainty can be a powerful motivator to implement security controls you otherwise neglect due to a misplaced sense of certainty. We all know you are far less likely to crash in a plane than to die in a car accident. Or that your children are far more at risk of drowning or (again) car accidents than of being abducted by a stranger. But we feel in control when driving a car, so we feel safer even though that’s flat-out wrong. You can’t control everything. Not your own systems or employees, no matter where they are located. Design for uncertainty, and you can better adapt to new opportunities or threats, at (I suspect, but can’t prove) the same costs. Not that you shouldn’t maintain some degree of control, but don’t assume control means security. Share:

I love my password manager. It enables me to use stronger passwords, unique passwords for every site, and even rotate passwords on select web services. You know, the sites that involve money. Because I can synch its data among all my computers and mobile devices, I am never without access. I believe this improves the security of my accounts, and as such, I am an advocate of this type of technology. I was encouraged when I saw the article Guard That Password in this Sunday’s New York Times. Educating users on the practical need for strong passwords in a mainstream publication is refreshing. Joe User should know how effective just a couple extra password characters can be for foiling attackers. On the downside, the article looks more like a vendor advertisement – in an attempt to reduce concerns over LastPass’s own security, the author seems to have missed describing the core values of a password manager. First a couple pieces of information that were missing from the article. One of its fundamental mistakes is that most merchants – along with the associated merchant web sites – don’t encrypt your password. On-line service providers don’t really want to store your password at all, they just want to verify your identity when you log in. To do this most sites keep what is called a ‘hash’ of your password – which is a one-way function that conceals your password in a garbled state. Each time you log in, your password is hashed again. If the new hash matches the original hash created when you signed up, you are logged in. This way your password can be matched without the threat of having the passwords reversed through the attacks described by Prof. Stross. Attackers still target these hashed values during data breaches, as they can still get figure out passwords by hashing common password values and seeing if they match any of the stolen hashes. In most cases you directly improve your password security by choosing longer passwords, thereby making them more difficult for an attacker to guess. All bets are off if the owner of a web site you visit does not secure your password. If the merchant stores unencrypted or un-hashed passwords – which is what Sony is being accused of – it requires no work for the attacker. You can’t force a web site owner to secure your password properly, and you can’t audit their security, so don’t trust them. The (generally unstated) concern is that people are bad at remembering passwords, so they use the same ones for eBay, Amazon, and banks. That means anyone who can decrypt or identify your password on a Sony site has a good chance to compromise your account on other (more lucrative) sites. Which brings us to my point for this post: using a password manager frees you from conventional problems, such as your memory. Your security is no longer dependent on how good your memory is. The commercial products all generate random strings with special characters for unguessable passwords. So why should we limit passwords to 10 characters? You no longer need to remember the passwords – the manager does this for you – so think 20 characters. Think 25 characters! And just as important, why limit yourself to one password when you should have a different password for every single site? This reduces the scope of damage if a site is hacked or when a merchant has crappy security. Finally, if you don’t trust the password manager to securely store your password in ‘the cloud’, you can always select a password manager that stores exclusively on your computer or mobile device. Password managers are one of the few times you can get both convenience and security at the same time, so take advantage! Share: