Research

Some days I think that in fitness, I’m getting wrong everything I advise people in security. I’ve been an athlete all my life – including some stints competing at a reasonably high (amateur) level. Like the time I went to nationals for my martial art. Cool, eh? Other than the part about getting my butt whipped by a 16-year-old. It seems cutting weight in a sport where knockouts aren’t the goal isn’t necessarily a good thing (me strong… me slow… puny teenager stand still so Hulk can kick in head, pleeze?). But running a startup and having kids seriously crimps my workout style. No more 20 hours of training a week, with entire weekends spent climbing or skiing some mountain. Here are a few of the ways in which I’m an idiot: I’m addicted to the toys. I currently use the Rolex of heart rate monitors (the Polar RS800CX). This thing connects to up to 4 external sensors at once to track my heart rate, position, and (I think) the fungus level of my little toe. Does it make me faster? Er… nope. So I’m spending for capabilities far beyond my needs. But damn, I really want that watch that counts my swimming laps. I bet I’d really use that one every day. I promise – now can I buy it? I’m a binge/purge sort of athlete. Rather than hitting a steady state of training and sticking with it, I’m on and off my program like a child actor at rehab. Oh, I always have great excuses like kids and travel, but as much time as I dedicate to working out, I tend to blow it with a bad month here or there. In other words some days I feel like I flit around worse than a horny butterfly with a narcissism problem. I get hurt. A lot. Then instead of fixing the root cause I freak out that I’m getting out of shape, jump back in at full speed, and get hurt again. I suppose I’m consistent (I have been on this cycle since I was a kid). On the upside, I get my money’s worth from insurance. I have delusions of grandeur. If some dude passes me on the bike I take it personally. Which is inconvenient, since most folks pass me on the bike. Or the run. Or… whatever. So I try to keep up, ignoring the fact that I train in places that attract professional athletes. Yeah, that doesn’t last too long. What really sucks is that as easy as it is to identify these problems, and much as I do (sometimes) work on them, I still make the same mistakes over and over. Okay, age has mellowed me a bit, but I’d quit my job and work out 8 hours a day in a heartbeat… … which I can measure with extreme accuracy thanks to my watch. And heck, after blowing out my knee by hour 6 I can go start work again. This is depressing. I think I’ll go sign up for a race… On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted on DAM market trends. Rich quoted in eWeek Europe. Rich on NetSecPodcast. Adrian’s Dark Reading Post on Federated Data. Mike’s monthly post on Dark Reading: Low And Slow, Persistence, Loud And Proud, And The Fundamentals. Favorite Securosis Posts Mike Rothman: Friction and Security. Wouldn’t it be great if we had KY Jelly for making everyone in IT work better together? Adrian Lane: Incite: The King of the House. Chicken McNuggets for vegetarians. Priceless. Rich: Call off the (Attack) Dogs. Other Securosis Posts (for 2 weeks because we skipped last week’s summary) Security Marketing FAIL: Claims of Risk Reduction. Tokenization vs. Encryption: Healthcare Data Security. Tokenization vs. Encryption: Personal Information Security. How to Encrypt or Tokenize for SaaS (and Some PaaS). Smart Card Laggards. Simple Isn’t Simple. Social Media Security 101. Incite 7/6/2011: Reading Between the Lines. Favorite Outside Posts Mike Rothman: Space Shuttle: good riddance. Count on Rob Graham to look at the situation, not the nostalgia, then bring it around to security. Compelling arguments about complexity and risk. Adrian Lane: How Digital Detectives Deciphered Stuxnet. Best article documenting Stuxnet I have read. Very entertaining. Rich: While not security specific, James Staten at Forrester has a good summary of this week’s cloud announcements. These are all pretty big developments that will affect your datacenter operations. Eventually. Pepper: Evgeny Kaspersky interviewed by Spiegel. Wide ranging and pretty interesting. Research Reports and Presentations Security Benchmarking: Going Beyond Metrics. 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). Network Security in the Age of Any Computing. The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Top News and Posts Anti-Sec is not a cause, it’s an excuse. Azeri Banks Corner Fake AV, Pharma Market via Krebs. SIEM Montage. Gotta have a montage! Anonymous Declares War on .mil. Microsoft Patches Bluetooth Hole in July’s Patch Tuesday. Intego Releases iPhone Malware Scanner. Jury’s still out. Google Removes All .CO.CC Subdomains Over Phishing, Spam Concerns. A Journey to the Cloud (Part 2). Inside the Chinese Way of Hacking. Police: Internet providers must keep user logs. Sony Exec Calls PlayStation Network Hack ‘A Great Experience’. In other news, he’s also really into S&M. 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 Michael, in response to Incomplete Thought: HoneyClouds and the Confusion Control. We will not be able to tell if the effectiveness of these Proteus tactics actually works, although I would welcome it. I do actually believe these tactics will work against certain people / bots. I am a big believer in time, the longer time it takes the more a person / bot is prone to give up and move

Every time I see the phrase “reduce your risk by X%,” I break out in hives. I agree that it is critical to think about risk (which to me is really about economic loss), but everyone has a different definition of risk. And to say anyone can reduce risk by a certain percentage triggers my bullcrap filter. Secunia recently did a study of their vulnerability database, which posits that if customers would patch only the 37 most popular Windows apps or their 12 most risky programs, they could reduce risk by 80%. There is that pesky word ‘risk’ again, because these numbers are questionable at best. They define risk as a sum of the number of vulnerabilities weighted by the criticality of the vulnerability. Huh? What about exploitability? Or the ability to exfiltrate data as required per the Data Breach triangle? How can you not factor in any other controls in place to mitigate and/or work around those ‘risks’? In fact, patching some of those apps is irrelevant because they pose no real risk to corporate assets. We are still fans of patching. In fact, it’s one of the anchor tenets of the Endpoint Security Fundamentals and a critical aspect of data center ops. I agree that most customers cannot patch everything within their typical maintenance windows, so some prioritization is necessary. But I’m not about to claim that patching will reduce anyone’s risk by an arbitrary percentage (or one calculated from an arbitrary formula). Any risk calculation needs to factor in the value of the data residing on the vulnerable device, not just the criticality of the vulnerability. For instance, what if a device has 50 critical vulnerabilities, but holds no corporate data? Is that a huge risk? I guess an attacker getting remote shell to the device could use it to stage further into the network, so that’s not good, but by itself that device doesn’t represent a real risk to the organization. Is it a bigger risk than a non-critical vulnerability on the server operating the business’ main transactional system? What would you patch first? Your patching process must include prioritization. If you are wondering how that works, Rich has done a ton of work on decomposing the granular processes of patching for our Patch Quant research – check it out. But we have beaten this horse enough. Let’s deal with the bigger issue: marketers’ efforts to quantify risk reduction. I’ve been there. The sales force needs some kind of catalyst to get customers to buy something. You figure if you do a little math, however wacky the assumptions, that will be good enough for customers to make a case to buy your stuff. You are wrong. It’s foolish to make blanket statements about risk reduction. Each organization’s perception of risk and its willingness to spend money to address or defer it is unique. But that won’t stop folks from trying. Despite my understanding, I still get annoyed by the attempts of security marketers to make bold statements with little real-world basis; and by the trade press biting hook, line, and sinker on pretty much anything described in percentages. But maybe that’s just me. Share:

Securing Personal Health Records (PHR) for healthcare providers is supposed to be the next frontier for many security technologies. Security vendors market solutions for Protected Health Information (PHI) because HIPAA and HITECH impose data security and privacy requirements. Should a healthcare provider fail in their custodial duty to protect patient data, they face penalties – theoretically at least – so they are motivated to secure the data that fuels their business. Tokenization is one of the technologies being discussed to help secure medical information, based on its success with payment card data, but unfortunately protecting PHR is a very different problem. A few firms have adopted tokenization to substitute for personal information – usually a single token that represents name, address and Social Security number – with the remainder of the data in the clear. But this use case is a narrow one. The remainder of the health-related data used for analysis – age, medical conditions, medications, zip code, heath care, insurance, etc. – can be used while the patient (theoretically) remains anonymous. But this usage is not very effective because it’s part of the medical, billing and treatment data that needs to be anonymized. It has not yet been legally tested, but a company may be protected if they substitute a person’s name, address, and Social Security number, even if the rest of the data should be lost or stolen. Technically they have transformed the records into an ‘indecipherable’ state, so even if a skilled person can reverse engineer the token back into the original patient identity, the company has reduced the risk of penalties. At least until a court decides what “low probability” means. So while there is a lot of hype around tokenization for PHI, here’s why the model does not work. It’s a ‘many-to-many’ problem: we have many pieces of data which are bundled in different ways to serve many different audiences. For example, PHI is complex and made up of hundreds of different data points. A person’s medical history is a combination of personal attributes, doctor visits, complaints, medical ailments, outsourced services, doctors and hospitals who have served the patient, etc. It’s an entangled set of personal, financial, and medical data points. And many different groups need access to some or all of it: doctors, hospitals, insurance providers, drug companies, clinics, health maintenance organizations, state and federal governments, and so on. And each audience needs to see a different slice of the data – but must not see PHI they are not authorized for. The problem is knowing which data to tokenize for any given audience, and maintaining tokens for each use case. If you create tokens for someone’s name and medical condition, while leaving drug information exposed, you have effectively leaked the patient’s medical condition. Billing and insurance can’t get their jobs done without access to the patient’s real name, address, and Social Security number. If you tokenized medical conditions to ensure patient privacy, that would be useless to doctors. And if you issue the same tokens for certain pieces of information (such as name & Social Security number) it’s fairly easy for someone to guess the tokenized values from other patient information – meaning they can reverse engineer the full set of personal information. You need to issue a different token for each and every audience, and in fact for each party which requests patient data. Can tokens work in this ‘many-to-many’ model? It’s possible but not recommended. You would need a very sophisticated token tracking system to divide up the data, issuing and tracking different tokens for different audiences. No such system exists today. Furthermore, it simply does not scale across very large databases with dozens of audiences and thousands of patients. This is an area where encryption is superior to tokenization. In the PHI model, you encrypt different portions of personal health care data under different encryption keys. The advantage is that only those with the requisite keys can see the data. The downside is that this form of encryption also requires advanced application support to manage the different data sets to be viewed or updated by different audiences. It’s a many-to-many problem, but is feasible using key management services. The key management must be very scalable key to handle even a modest community of users. And since content is distributed across multiple audiences who may contribute new information, record management is particularly complicated. This works better than tokenization, but still does not scale particularly well. If you need to access the original data at some point in the future, encryption is your only choice. If you don’t need to know who the patient is, now or in the future, the practical alternative is masking. Masking technologies scramble data, either working on an entire database or on a subset of the data. Masking can scramble individual columns in different ways so that the masked value looks like the original – retaining its format and data type just like a token – but is no longer sensitive data. Masking also is effective for maintaining aggregate value across an entire database, meaning the sum and average values within the data set can be preserved while changing all the individual data elements. Masking can be done in such a way that it’s extremely difficult to reverse engineer back to the original values. In some cases, masking and encryption provide a powerful combination for distribution and sharing of medical information. Tokenization is an important and useful security tool with cost and security advantages in select use cases – in some cases tokens are recommended because they work better than encrypted data. The goal is to reduce data exposure by reducing the number of places sensitive data is stored – using encryption, tokenization, masking, or something else. But every token server still relies on encryption and key management to safeguard stored data. End users may only see tokens, but somewhere in the tokenization you can always find encryption services supporting it. We recommend tokenization in various

With the two girls at sleepaway camp, the Boss and I weren’t sure how the Boy would handle it. After all, he’s pretty much always surrounded by someone. Having a twin sister will do that to you. If he’s not at school, with his buddies, or doing an activity, he’s usually playing with one of his sisters. In fact, we think his ability to tune out almost everything directly correlates to always being around people. But don’t think the summer is only fun and games. I described Mommy Food Camp last week, and he’s doing well. He eats hot dogs now (“I don’t like them, but I’ll eat them”), and I even got him to eat a hamburger (“It was horrible!”). He’s now thinking of becoming a vegetarian (like his Dad), and tried to convince me that there’s no meat in Chicken Nuggets. He may actually be right, but that’s another story. We were also hoping he would become a bit more assertive, as he tends to be pretty quiet. We learned this was a non-issue when he had a tantrum at day camp when he wasn’t in a group with his buddies. Suffice it to say, the situation was rectified immediately, and we didn’t have to get involved. Of course, we’d like him to deal with things without crying and screaming, but he has friends who were put in the wrong group and didn’t say a word for days. We’ll take Mr. Assertive any day of the week. Truth be told, I think he likes the peace and quiet. We joke that the only time he had any peace was the minute after his sister was born, while he was waiting his turn. We do let him play on one of the iPads a bit and maybe watch a little TV, but nothing crazy. We’re glad he’s enjoying the few weeks he’s flying solo because the plan is to send him to sleepaway camp next year. Even though he maintains that he doesn’t miss his sisters, we make him write letters to them anyway. It’s as much to keep him writing as anything else, though we know the girls love to hear from him. He wrote a nice letter, telling them what’s he’s been up to, who he’s been hanging out with, and that he just lost another tooth and is awaiting the Tooth Fairy’s visit. At one point in the letter, he wrote: “I’m the King of the House.” We wondered whether we should pull that out, since it might make the girls feel bad, but decided to leave it in. Mostly because it was so damn cute. But when we dug a bit deeper, clearly the Boy does get overshadowed by his strong-willed sisters. With them not around (for a little while anyway), he assumes the mantle of the King. Of course, I don’t have the heart to burst his bubble. He’s no more the King of the House than I am. But that didn’t stop us from asking the King to clean up his dishes and get ready for bed. Even royalty needs beauty sleep. -Mike Photo credits: “KING CLUB” originally uploaded by oknovokght Incite 4 U The Daily Breach: Given the challenges of traditional media, it’s surprising that none of the tech books have launched a Daily Breach newsletter. It’s not like there’s no inventory. I mean, check out this screen grab of my SC Magazine newsletter this AM. 4 latest news stories, and 4 breaches. And that doesn’t even include the Booz Allen breach. Folks, this is the new reality. Breaches happen. Breaches are disclosed. Customers are pissed. Some folks would use a data point like this as an excuse to be grumpy or to do nothing. But there has always been a Daily Breach. You just didn’t know about them before. So now the spotlight is on us. Guess we should have been careful what we wished for. – MR Just do the work, or hire crap: Let’s look at A List Apart’s recent post on “RFPs: The Least Creative Way to Hire People”. You don’t need to be creative to hire people – you want to hire creative people (whether or not you yourself are). I have seen just as many bad creative hiring methods as bad conventional ones – both unwittingly filter due to the process. Have I even mentioned the time I was interviewed by 115 people for a VP of Engineering Job? Only two interviewers actually understood the skills needed for the job, and one interviewer wanted a bad candidate to ensure there was no challenge for her fiefdom. However it’s done, you just need to put in the time to understand what you are hiring for and adequately screen the sea of resumes. It’s the latter point that people don’t want – or know how – to do. So they create, effectively, giant lists of screening questions to filter the resumes. But here is a hint: PEOPLE LIE. Liars get through, and honest people don’t. Forget all the other fancy nonsense, put in the time, and do the work. – AL Know thyself: Managing your identity online is more than merely controlling your credentials and avoiding keyboard-mediated tourettes (something I should probably work on). In the real world our lives are naturally compartmentalized. There’s work, home, hobbies, groups, and all sorts of social circles. The online world isn’t really set up like this, and when we use work email accounts for personal communications, or tie our identities to our jobs, or link in everyone on the same social media platforms, we blur lines in ways we cannot always anticipate. That’s why Jeff Jones’ article on how he’s segregating his identities really resonated with me. I did something similar a while ago – Twitter is fully public, Facebook is now for (mostly) non-work friends and family only, and I’ve switched more personal email off Securosis, despite being a partner in the company. Think about your online personae, and it

In my last post I discussed how tokenization is being deployed to solve payment data security issues. It is a niche technology used almost exclusively to solve a single problem: protecting credit card data. As a technology, data tokenization has yet to cross the chasm, but our research indicates it is being used to protect personal information. In this post I will talk about using tokens to protect PII – Social Security numbers, driver’s license numbers, and other sensitive personal information. Data tokenization has value beyond simple credit card substitution – protecting other Personally Identifiable Information (PII) is its next frontier. The problem is that thousands of major corporations built systems around Social Security numbers, driver’s license numbers, or other information that represents a person’s identity. These data were engineered into the foundational layers of myriad applications and business processes which organizations still rely on. The ID (record number) literally tied all their systems together. For example, you could not open a new telephone account or get an insurance policy without supplying a Social Security number. Not because they needed the number legally or technically, but because their IT systems required the number to function. SSNs provided secondary benefits for business analysis, a common index for 3rd party data services, and useful information for fraud detection. But the hard requirement to provide SSN (or driver’s license number, etc.) was that their application infrastructures were designed to require these standard identifiers. PII was intrinsically woven into database and application functions, making it very hard to remove or replace without negative impact on stability and performance. Every access to customer information – billing, order status, dispute resolution, and customer service – required an SSN. Even public web portals and phone systems use SSN to identify customers. Unfortunately, this both exposed sensitive information to employees with no valid reason to access customer SSNs and contributed to data leakage and fraud. Many state and local government organizations still use SSNs this way, despite the risks. Organizations have implemented a form of tokenization – albeit unwittingly – by substituting SSN and driver’s license numbers with arbitrary customer ID numbers. Social Security numbers are then moved into secure databases and only exposed to select employees under controlled circumstances. These ad hoc home-grown tokenization implementations are no less tokenization than the systems offered by payment processors. A handful of organizations have taken this one step further, used third-party solutions to manage token creation, substitution, data security, and management. But there are still thousands of organizations with sensitive data in files and databases to identify (index) clients and customers. PII remains a huge potential market for off-the-shelf tokenization products. While this is conceptually simple, and simply a good idea for security, not every company uses tokenization for PII – either commercial or ad hoc – because they lack sufficient incentive. Most companies lack strong motivation to protect your personal information. If it’s lost or stolen, you will need to clean up the mess. There are many state regulations that require companies to protect PII and alert customers in the event of a data breach. But these laws are not adequately enforced, and provide too many loopholes, so very few companies ever face fines. For example, most laws are designed to excuse breaches if data encryption was in use. So if a company encrypts network communications, or encrypts data archives, or encrypts your database, they may be exempt from disclosure. The practical upshot is that companies encrypt data in one context – and escape legal penalties such as fines – while leaving it exposed in other contexts. The fact that so many data breaches continue to expose customer data clearly demonstrates the lack of effective data security. Properly deployed, encryption is a perfectly suitable tool for protecting PII. It can be set up to protect archived data or data residing on file systems without modification to business processes. Of course you need to install encryption and key management services to protect the data, understanding this only protects data from access that circumvents applications. You can add application layer encryption to protect data in use – but this requires changing applications and databases to support this additional protection, paying the cost and accepting the performance impact. In cases like PII – which really is not needed for the vast majority of application functions – tokenizing personal information reduces the risk of loss or theft without impacting operations. Risk is reduced because you can’t steal what’s not there. This makes tokenization superior to encryption for security: If encryption is deployed insecurely, if administrative accounts are hijacked, or if encryption keys are compromised, the data is exposed. Tokenization simplifies operations – PII is stored in a single database, and you don’t need to install key management or encryption systems. Setup and maintenance are both reduced, and the number of servers which require extensive security is also reduced. Tokenization of PII is often the best strategy as it’s cheaper, faster, and more secure than alternatives. Share:

A few weeks ago I posted on different methods for encrypting IaaS volumes, which tends to be one of the top questions I get about data security in the cloud. Also high on that list is encrypting (or tokenizing) for SaaS and (some) PaaS. I call this the “Salesforce.com Problem”, because more often than not I’m talking to someone on the larger side, specifically about Salesforce.com. Before I go into options, I need to explain why I’m only talking about some PaaS. PaaS covers a very wide range of technologies – from Database as a Service, to things like Google APIs, to full-on application environments like CloudFoundry and Elastic Beanstalk. For this post I’m mostly restricting myself to SaaS-related PaaS like Force.com. In other words, API interfaces to things you can also run completely via a web interface. I know this is a grey line, and in some future post I’ll go more into detail on encrypting for the rest of PaaS. Just recognize that the core architecture described here works for cases beyond this scope, but some of the issues & details may not apply. There are only two options for SaaS encryption: Encrypt it at the SaaS provider. Encrypt it before you send it. To review quickly, when analyzing encryption systems we look at the locations of three components: the data, the encryption engine, and key management. If your SaaS provider handles the encryption on their side, they hold all three components, so this option requires trust in your provider. Yes, there are many subtleties and options that dramatically affect security, but at the core the provider needs the key and the data at some point. The advantage (for you) is simplicity and flexibility. But if you don’t trust your SaaS provider, you’ll need to encrypt on your side… which means increased cost and complexity. If you encrypt it before you send it, there are two options: Encrypt in a client application before uploading the data. Proxy connections and encrypt at the proxy. The first option is common for things like backup applications, but as I mentioned that’s more PaaS – the part we aren’t talking about here. Espcially because the vast majority of the apps I am talking about today are web-based. So most organizations I know which are looking to do this are evaluating proxy-based solutions such as CipherCloud, PerspecSys (maybe – their website sucks and doesn’t mention how they work), and Navajo Systems. These are application-aware web proxies that intercept browser calls to the SaaS provider and replace sensitive data with encrypted or tokenized values. Instead of connecting directly to the SaaS provider, users go through the proxy. You configure it to encrypt or tokenize sensitive data, although instead of defining every field on every form you should be able to say “account number” and have the product automagically replace it everywhere. In some future post I’ll delve into this architecture in more depth, but there are three main challenges to this approach: The product needs to stay totally up to date with any changes with the SaaS provider UI/application. When you are intercepting and rewriting HTML fields on the fly, you really need to know exactly where they are. Users need to connect back through your enterprise, or a trusted web-based host (e.g., running the proxy at Rackspace). For your internal network, this means you’re back to running VPNs. If you host on the outside, you have another party to trust but can handle it with bookmarks or such. If you use a cloud-based web proxy for URL filtering and content security, you might be able to map it up there. You might break application functionality/usefulness. This requires a lot of translation, which affects SaaS features that rely on the protected data. This becomes more of an issue as you protect more fields and data types – the more you obfuscate, the less your SaaS app can process. (It can still process the un-tokenized data). Because of these challenges I tend to regard this proxy approach as a band-aid for SaaS. It’s definitely not ideal, and a heck of a lot of work for the vendor to keep up and running. I believe it makes more sense for PaaS, where you rely more on APIs than HTML interfaces. In all cases I think the web proxy approach is best used for very discrete and limited data – otherwise there is too much potential loss of core application functionality, at which point you might as well stick to internal systems. Share:

Every company I have worked for has had some degree of friction between sales and marketing teams. While their organizational charters are to support one another, sales always has some disagreement about how products are positioned, the quality of competitive intelligence, the quality of leads, and the lack of <insert object here> to grease the customer skids. Marketing complains that sales does not follow the product sales scripts, doesn’t call leads in a timely fashion, and don’t do a good job of collecting customer intelligence. Friction is a natural part of the relationship between the two organizations, so careful balancing is necessary. I was reading George Hulme’s interview David Litchfield on securing the data castle this morning, which provides basic security steps every organization should take. There’s also a list of intermediate Oracle security controls (PDF). But the real challenge was not performing Litchfield’s steps – it’s managing the resulting friction. The issue is that problems arising between database administrators and everybody else. Litchfield says: Beyond patch updates and good password management, what else can organizations be doing that they’re not? Use the principle of least privilege within their applications. This is a very important one. People are pressured into getting their applications running as quickly as they can. However, when they try to manage permissions properly, that good practice can delay deployment slightly. So they say, “Oh look, let’s just give users all the permissions. The application seems to work with these settings. Let’s shove that into production.” Not a great approach. If you don’t want a breach, it’s really worth spending the extra time to design an application that operates on least privilege. Which is all true, but only one side of the coin. For example, setting permissions is easy. Managing and maintaining good permissions over time is more work and creates friction between organizations. Most DBAs face user calls on a daily basis, asking for added permissions to complete some task. Users look at permissions – or their lack – as impediments to getting their jobs done. Worse, should the DBA decline the request, the DBA takes the blame for lost time. DBAs need to add the permissions and then – at some prearranged time – revoke them. But most DBAs, looking to avoid future calls to add privileges, never revoke them. It’s easier and less hassle, and users are happier. Face it – a few minutes of wasted time for both parties, especially with hundreds or even thousands of users, adds up to a lot of time. Who’s going to notice? Patching is the same – upgrade an application or database revision and stuff breaks. Or just as bad, the application works differently than before. New features and functions create complaints like “What happened to X?” and “It used to do Y, but now it doesn’t!”, so for several weeks the help desk is swamped with calls. And password rotation and long password requirements both generate help desk calls by the dozen. So what’s the result? User complaints. Systems are not reliable, which results in the poor DBA getting a poor ‘performance’ rating. Which is sad because the friction between user demands for everything and DBAs holding the line for security is a sign that DBAs are doing their jobs. But doing their jobs gets them dinged on performance, so they don’t get raises, so they leave for other jobs. Any good DBA understands that there is a correct degree of friction in their role for security. It’s not just planning for the security measures you want to put in place, but understanding how to mitigate their impact on the organization. Plan ahead and don’t let security be “your fault”. Share:

I have to admit that some days I have no idea what will resonate with readers. For example, my latest column over at Dark Reading seems to be generating a lot more interest than I expected. For a few months now I’ve been bothered by all the pile-ons every time some organization gets hacked. Sure, some of them really are negligent, and others are simply lazy or misguided, but the rest really struggle to keep the bad guys out. There’s never any shortage of experts with hindsight bias ready to say X attack would have been stopped if they only used Z security best practice. It’s like a bunch of actors sitting around going “I could have done it better”. Frequently this ‘advice’ is applied to a large organization which “should know better”. But these critics consistently fail to account for the cost and complexity of doing anything at scale, or for (universal) resource constraints. This was the inspiration behind Simple Isn’t Simple. Here’s a quote: This isn’t one of those articles with answers. Sure, I can talk all day about how users need to operationalize security more, and vendors need to simplify, consolidate, and improve functionality. But in the end those problems are every bit as hard as everything else I’m talking about and won’t be solved anytime soon. Especially since the economics aren’t overly favorable. But we can recognize that we rely on complex solutions to difficult problems, and blaming every victim for getting hacked isn’t productive. Especially since you’re next. Security is hard. It’s even harder at scale. And we need to stop pretending that even the most basic of practices are always simple, and start focusing on how to make them more effective and easier to manage in a messy, ugly, real world. I thought is was the usual analyst BS, but I guess there’s something more to it… Share:

The US is playing ‘catchup’ in contactless security. The US lags in smart identity card technology adoption. We lag in payment card security. It’s frustrating for Americans to travel in Europe. We have rudimentary ePassport technology, and it has been almost a decade since the first draft of the HSPD-12 PIV standards. We’re behind. We are laggards. And I say “So what?” When it comes to smart card adoption, the US is not even in the race. Citizen ID, government employee ID, ePassports, first responder cards, Chip and PIN payment cards, whatever – we are in no hurry. And I am not at all convinced we should be in many cases. Credit card fraud rates in the US are not much higher than Europe’s. Sure, it’s still pretty easy to ‘skim’ credit cards – but not enough to rework the entire payment infrastructure to accommodate Chip & PIN systems. Are people breaching the security of federal buildings due to the lack of advanced PIV cards? How many terrorist attacks on RFID systems have you seen? Many of the efforts are technology for the sake of technology. You’re getting new technology, at 10 times the cost, for only slightly better security. Like those motorized paper towel dispensers or automated Japanese toilets – sometimes technology was not a necessary solution. I am amused that smart card, ePassport, National ID, and PIV vendors market their products as benefits to the consumer. Do you know anyone who thinks their life would be better if they had a smart national ID card? Me either. And the only time I have even heard about problems around the lack of EMV (Europay-Mastercard-Visa alliance) smart cards is in the last few months for US travelers in Europe. Even then there are plenty of solutions if you plan ahead. The noise on this subject seems to be coming from the SmartCard alliance and associated organizations – not from consumers, merchants, or even the payment card industry. It’s not that we lack the technology, it’s that we lag in deployment of the security technologies. So why is that? Because there is not enough financial justification for the expense. It would cost billions to swap merchant payment terminals, and possibly billions to issue new cards, given the investment in back-end personalization and issuance systems to produce the cards. The fact that many of the security problems have been mitigated with fraud detection and other forms of authentication offsets the need for these smart token systems. It’s a classic security vs. business tradeoff. Do we really really need Chip and PIN in the US? Will it keep us more secure? Will it drop credit card fraud enough to offset the cost of replacing the infrastructure? Does it reduce merchant liability? Are RFID systems really being hacked for fun and profit? Not enough to warrant adoption today, at least. Ultimately we’ll see smart cards with increasing frequency as things like multi-app EMV cards offer more business opportunities, but the motivator will not be security. Share:

It won’t surprise any of you to learn that I don’t follow Fox News on Twitter. I know, I can see the shock in your eyes, but I’m not the biggest fan of our friends on the right. Actually, I hate all 24 hour news stations – Fox biased to the right, MSNBC to the left, and CNN to the stupid. So I missed their announcement of to the demise of our commander in chief. It seems one of their Twitter accounts was hacked, and the attackers had a little fun with some bogus tweets. If you read this blog you probably know everything I’m about to write, but it’s probably a good time to review it anyway. If you use these services for business purposes, there are a few precautions to put in place: If you use social media in your business, make sure you set up accounts (or use your personal accounts) to monitor your official account. Be very cautious in how you handle your account credentials (who you give them to, how they are secured, etc.). The list of people with access should definitely be very short. Use an OAuth-based service or application to allow employees to tweet to your account without having to give them your account password. This is how most Twitter clients work today, for example. If you are large enough, talk to your provider ahead of time to understand how to report problems, and who to report them to. The last thing you want to be doing is hanging out waiting for a help desk person to see your request in the queue. Make contact, get a name, and establish a validation process to prove you are the owner of the account in an incident. You’ll also use this process if an employee goes rogue. Simple stuff, but I suspect very few businesses follow these basics. Share: