Research

‘Did you buy one of the deeply discounted Plasma Televisions this weekend? How about a new digital camera? How about eBay? No, not something being sold there, but the company itself. Chris O’Brien over at the San Jose Merc speculates on what it would take to buy the auction site as there have been some rumors floating around on this subject, and indirectly points out why cash is king. Meanwhile while the London times claims Microsoft was doing a little Black Friday shopping of it’s own, another rumor that probably will not die until it is no longer a rumor. What the heck, take half off and let the Holiday rush begin! Share:

‘This Sunday’s Arizona Republic picked up Brian Krebs article in the Washington Post about thieves tapping into home equity lines of credit. This is a very interesting, and just because their are people out there who actually still have home equity, but that this is a very simple con with potentially devastating affect. One of which is there was no data theft here, rather the information was mined legally. Second is that when the bank falls for the con, since they believe it was the borrower who made the withdrawal, the borrower has to detect the fraud and provide some form of evidence that it was not they that made the withdrawal. After I read this story, I went out to see what data was available to see if this was possible. Despite a wife who uses this information on a daily basis to perform her job, I was still surprised. The amount and quality of information that is held in public databases, readily accessible to anyone who cares to view it is pretty amazing. If you are not aware of it, when you buy a home, pretty much every piece of information regarding that transaction is logged by the county recorder and placed in the public domain. If you are a homeowner, go out to your county recorders web site and search for the data; your name, address, signature, lender, the amount, possibly the interest rate and a lot of other information as well. Seriously, take a minute and check it out; I think you will be startled as to what you find. Stars, celebrities, politicians along with everyone else. In this particular case there was no data theft theft component in this particular case, rather it was simple and legal data mining for ID theft. They probably were able to cross reference those people who looked like they may have assets with a credit score, and voila, instant target list. A lot of people have had their HELOC, or Home Equity Line of Credit yanked from their banks recently, some amid remodeling projects. Part of the issue is the Banks trying to reduce their exposure on people who are living off their credit lines, but another is this type of fraud. Banks and financial institutions have long had the problem of ‘how do I know its really you’, and thieves often know in advance what the banks ask for in the way of authentication, and either have that information, or a suitable excuse. Had the group in this specific case not been so greedy and tied to move such a large sum of money, I am not sure they would have been caught. And since the perpetrator is able to mask their identity and location, it’s up to the bank’s representative to have enough savvy to not fall for the con. And in that event, it’s trouble for both the lender and hassle for the borrower, so check your statements as this could happen to pretty much anyone. Share:

PayPal announced their Mobile PayPal offering this week. Really nothing new here from a technology standpoint as it leverages existing services and the Verisign/PayPal security key. Why I was interested in the release was the signal that they are putting more resources behind this market. I am still shocked that payment via cell phone did not catch on like wildfire in US. Look at adoption rates of cell phones, SMS, twitter and the like, and I would have bet that payment would have been right there with them. Small dollar, in context, person to person, embedded payments could be easily provided. I saw my first payment via cell phone method in 1996 through one of the major European cell phone providers. Built a system capable of providing ‘micro-payment’ over the phone in 1997. Nada. No interest from the public. Still, it would be far safer for me to pay for that thing I bought on eBay over the cell phone than using the Internet access for whatever hotel I am usually staying in. Need remains, so I am very interested in seeing how customers react to this recent announcement. There are plenty of other companies who offer quality service but struggle with adoption. Startups like Obopay have done a good job in building awareness and vendor relationships (with banks & telecommunications carriers) needed to succeed in this market. But while they may be winning the war with the tiny providers like CellPay, Paymate, TextPayMe and countless others, they are at a disadvantage in a couple of ways. First, these vendors typically build a new payment mechanism, unlike PayPal, who is simply a wrapper on existing infrastructure. Second, even if they do come up with a novel approach, most likely what they have done is build a blueprint for the larger providers as they are not large enough to make a market. After 10 years I think we have proven there is not going to be viral adoption, so the smaller players are going to have a very tough time if PayPal’s offering is adopted by their customers, something neither the banks nor the cell providers have been able to leverage. Now I am off for a long weekend. Have a great Thanksgiving Holiday! Share:

When I was with IPLocks in the 2004 time frame, we were exploring the possibility of selling our monitoring and assessment suite into the government. Friends and contacts made introductions, and we began investigating if there was a need for the solution, and if so, how we would approach tackling that type of relationship. While we knew dealing with the government would be tough, we felt that any organization that is sitting on piles of personally identifiable information and literally hundreds of thousands of databases would be a natural fit for our technology. After a few months of analysis process we decided we couldn’t do it. Too much in the way of time and resources, and too much uncertainty about what we needed to do. Going through the process was simply too long and too difficult for a small company like ours to undertake. We had a technology that could solve problems in different branches of the government, but this is not like the private sector where vendor meets customer, product meets need, and we write up a contract. There are far more demands and restrictions, and the more we learned, the more we felt we will missing basic knowledge of all of the steps in the process. Or even what the process was, for that matter, or which systems integrator we should approach, we did not know if we needed to focus on specific branches of the government, nor were we even aware of all of the accreditations and certifications our product would need to go through. The risk was too great and we walked away. This is a common problem and one to be expected. I run into vendors at every trade shows who are in the same boat; a desire and a good technology fit, not a clue as to where to start. A couple years ago, my friend Robert Rodriguez helped found the IT Security Entrepreneurs forum with the intention of tackling this type of problem and provide a way to “bridge the gap” between Federal agencies and private industry. From his perspective he saw both the desire from the vendors side to participate, but also the need from the government side to have security products that were, how do I say this, from the current decade. But the process does not favor this sort of innovation, rather it is the larger firms that can afford the time and resources to last through the effort, with the smaller and mid sized vendors getting filtered out. Smaller firms with innovative technologies typically cannot compete. Various arms of the US Government are supporting this effort to address the problem by offering educational resources and contacts, and the forum’s web site will host much of that information freely to the public. If you are serious about selling to the government, there is also a conference in March dedicated to this topic, and it is well worth the $400 fee. Past events have had a number of very good speakers from the security industry, academia, DHS and the US Military, along with some very eye-opening comments from the behind-the-scenes administrators who run the procurement side of the process. Once you understand the issues from the other side of the table, it makes things a lot clearer about what you need to do and why. Plus a lot of the VC, resellers and system integrators are in attendance, and they help small firms avoid common mistakes, wasted efforts and provide some plain speaking advice on what you need to do to sell to the government. If you have ever sifted through the online tomes of government requirements written in that special form of legal-ese, you know why that is of value. Share:

I installed Parallels 4.0 on the iMac last week, upgraded my licenses and converted my bootable images to the new format. It took a while to do as the conversion process takes a long time. While the installation was trivial, I had 4 different bootable images to convert, which took a good 3 hours to migrate even though they were only a couple of gigabytes a piece and only have a handful of applications installed. But I had no problems and everything worked fine. There are a couple subtle changes to the interface that make management of the images a little easier. I have not witnessed the performance enhancements that are claimed to be present, but I have not had performance issues in the past, so your mileage may vary. As the build I used was the one provided right after the official announcement, I was expecting that a new one would be released soon to clear up some small issues that have popped up. Sure enough, build 4.0.3540.209168 popped up today. Problem is I cannot install it. The ‘Continue’ button is grayed out; tried a couple of times, but there are really no options other than to accept and continue, but still I cannot proceed. I cannot imagine something this simple not getting picked up by QA. Anyone else out there having this issue? Share:

I swore that I was not going to cover data ‘breach’ events unless there was something that was really interesting or unique about it. There are too many and the general public has grown desensitized as the number of records and the overall number of breaches is, well, mind numbing. But this caught my eye as I think I may have taken photos of this house when it went back to the bank: Boxes containing loan applications, Social Security numbers and bank account information for residents of a Gilbert neighborhood have been discovered in a ransacked model home abandoned by a bankrupt developer. Several Higley Park model homes have been broken into since builder Randall Martin ceased operations. One home even had its garage door stolen, residents say. Julio Gonzalez, member of an ad hoc committee of Higley Park residents, found the boxes of paperwork when he was surveying the damage to the model homes. This sort of thing is going to be a lot more common in the coming months: bankrupt businesses throwing their files in the trash, or in this case, just leaving them behind in the building and walking away. Weird that the police wanted nothing to do with the files as I would think this is evidence of a crime. Share:

I kind of get a chuckle from articles like this recent series at Dark Reading on phishing, spam and malware. First came the contradictory posts, both posting that Phishing Attacks are reaching record highs, while simultaneously trumpeting that the king of spam and botnets had been shut down. I don’t suppose it dawned on the editors that if the channel that conveys the phishing attacks is “shut down”, then we are not likely to see “Record Highs.” Then there is the headline that November 24th, the biggest shopping day of the year, could be a “Black Monday” in terms of malware threats … “PC Tools predicted Nov. 24 would be the most active day for malware threats after analyzing worldwide virus data on more 500,000 machines and data from last year’s holiday season”. Then again, maybe not: “And while spam and malware typically surge during the holiday season, this year may actually be a little less active than in years past, says Roger Thompson, chief research officer at AVG Technologies. No one should be especially worried about Nov. 24 …”. Um, yeah. I am all for articles with interesting & topical information, and I understand the need to balance both sides of an issue, but if you are going to use attention grabbing headlines about some huge threat, you should at least provide some links or direction on what to do about it. Missing from all of this was a singularly relevant piece of useful information that most end users could easily use to help themselves in the battle against phishing and malware attacks, namely: DON’T CLICK EMBEDDED EMAIL LINKS. Share:

Rich posted an article on database and media encryption (aka Data at Rest) earlier this week, discussing the major alternatives for keeping database media safe. Prior to posting it, he asked me to preview the contents for accuracy, which I did, and I think Rich covers the major textbook approaches one needs to consider. I did want to add a little color to this discussion in terms of threat models and motivation- regarding why these options should be considered, as well as some additional practical considerations in the use and selection of encryption for data at rest. Media Encryption: Typically the motivation behind media encryption is to thwart people from stealing sensitive information in the event that the media is lost or stolen, and falls into the wrong hands. If your backup tape falls off the back of a truck, for example, it cannot be read and the information sold. But there are a couple other reasons as well. Tampering with snapshots or media is another problem encryption helps address, as both media and file encryption resist tampering- both in long-term media storage, and file/folder level encryption for short-term snapshots. If a malicious insider can alter the most recent backups, and force some form of failure to the system, the altered data would be restored. As this becomes the master record of events, the likelihood of catching and discovering this attack would be very difficult. Encrypted backups with proper separation of duties makes this at least difficult, and hopefully impossible. In a similar scenario, if someone was to gain access to backups, or the appliance that encrypts and performs key management, they could perform a type of denial of service attack. This might be to erase some piece of history that was recorded in the database, or as leverage to blackmail a company. Regardless of encryption method, redundancy in key management, encryption software/hardware, and backups becomes necessary; otherwise you have simply swapped one security threat for another. External File or Folder Encryption. If you rely on smaller regional database servers, in bank branch offices for example, theft of the physical device is something to consider. In secured data centers, or where large hardware is used, the odds of this happening are slim. In the case of servers sitting in a rack in an office closet, this is not so rare. This stuff is not stored in a vault, and much in the same way file and folder encryption helps with stolen laptops, it can also help if someone walks off with a server. How and where to store keys in this type of environment needs to be considered as well, for both operational consistency and security. Native Database Object Encryption: This is becoming the most common method for encrypting database data, and while it might sound obvious to some, there are historical reasons why this trend is only recently becoming the standard. The recent popularity is because database encryption tends to work seamlessly with most existing application processes and it usually (now) performs quite well, thanks to optimizations by database vendors. As it becomes more common, the attacks will also become more common. Native database encryption helps address a couple specific issues. The first is that archived data is already in an encrypted state, and therefore backups are protected against privacy or tampering problems. Second, encryption helps enforce separation of duties provided that the access controls, group privileges, and roles are properly set up. However, there are a number of more subtle attacks on the database that need to be considered. How objects and structures are named, and how they are used, and other unencrypted columns, can all ‘leak’ information. While the primary sensitive data is encrypted, if the structures or naming conventions are poorly designed, or compound columns are used, information may be unintentionally available by inference. Also, stored procedures or service accounts that have permissions to examine these encrypted columns can be used to bypass authorization checks and access the data, so both direct and indirect access rights need to be periodically reviewed. In some rare cases I have seen read & write access to encrypted columns left open, as the admin felt that if the data was protected it was safe, but overwriting the column with zeros proved otherwise. Finally, some of the memory scanning database monitoring technologies have access to cached data in its unencrypted state, so make sure caching does not leave a hole you thought was closed. Hopefully this went a little beyond specific tools and their usage, and provided some food for thought. You will need to consider how encryption alters your disaster recovery strategy, both with the backups, as well as with encryption software/hardware and key management infrastructure. It affects the whole data eco-system, so you need to consider all aspects of the data life-cycle this touches. And some of you may consider the threats I raised above as far-fetched, but if you think like a criminal or watch the news often enough, you will see examples of these sorts of attacks from time to time. Share:

Google is launching a cooperative program between Google and Medicare of Arizona. They are teaming up to put patient & health care records onto Google servers so it can be shared with doctors, labs and pharmacies. Arizona seniors will be pioneers in a Medicare program that encourages patients to store their medical histories on Google or other commercial Web sites as part of a government effort to streamline and improve health care. The federal agency that oversees Medicare selected Arizona and Utah for a pilot program that invites patients to store their health records on the Internet with Google or one of three other vendors. From Google & Medicare’s standpoint, this seems like a great way to reduce risk and liability while creating new revenue models. Google will be able to charge for some add-on advertisement services, and possibly data for BI as well. It appears that to use the service, you need to provide some consent, but it is unclear from the wording in the privacy policy if that means by default the data can be used or shared with third parties; time will tell. It does appears that Google does not assume HIPPA obligations because they are not a health care provider. And because of the voluntary nature of the program, it would be hard to get any satisfaction should the data be leaked and damages result. The same may be true for Medicare, because if they are not storing the patient data, there is a grey area of applicability for measures like CA-1386 and HIPPA as well. As Medicare is not outsourcing record storage, unlike other SaaS offerings, they may be able to shrug off the regulatory burden. Is it just me, or does this kind of look like Facebook for medical records? Share:

I was reading the RSA report on the Torpig/Sinowal trojan while stuck at the airport for several hours last Thursday. During my many hours of free time I overheard some IT executive discussing the difficulties of implementing data discovery and classification with his peers. I did not catch the name of the company, and probably would not pass it along even if I had, but the tired and whiny rant about their associated failures was not unique. Perhaps I was a bit testy about having to sit in an airport lobby for eight hours, but all I could think was “What is wrong with you? If hackers can navigate your data center, why can’t you?” That’s where the RSA report just gelled my thoughts on the subject. If a small group, quite literally a handful of hackers, can use Torpig & BlaBla to steal hundreds of thousands of credit card numbers, steal accounts and passwords, install malicious software at multiple company sites … all without being provided credentials, access rights or a specific map of your IT infrastructure … why can’t your company classify its own data and intellectual property assets? You would think that a company, given a modest amount of resources, could discover, classify and categorize its own data. I mean, if you paid someone full time to do it, don’t you think you could get the job done? Some of the irritating points that they raised … “Data in motion made it difficult to track”: So what- the hacker tools are kept running and they never stopped scanning. Nor did they give up on the first try; rather they periodically modified their code to adapt for location and type of data, and they were persistent. You should be too. “Difficulty to classify the data” and “Can’t find stuff you know is there”: So what- hire better programmers. Pressure vendors for better tools. Can’t afford expensive software? There is open source code out there to start with; hackers can do it, so can you. There is at least a dozen programatic ways to analyze data, through content or even context, and probably even more ways to traverse/crawl/inspect systems. If the application your company uses it can find it, so can you. “Size of the project is difficult to manage”: So what- divide and conquer. Take a specific set of data you are worried about and start there. Compliance group breathing down your neck to meet XYZ regulation? Pick one category (customer accounts, credit card data, source code, whatever. Tune your tools and policies (you did not really think you were going to get perfection out of the box did you?), address the problem and move on. If you are starting with an ISACA or Cobit framework and trying to map a comprehensive strategy, stop making the problem more complex than it is. Hackers went for low hanging fruit; you should too. “The results are not accurate”: So what- your not going to be 100% right all the time. The hackers aren’t either. Either accept 95-99% accuracy, or try something different. Or maybe your policy is out of line with reality and needs to be reconsidered. “Expensive” and “Takes too much in the way of resources”: No chance! If hackers can run malware for 18 months at TJX and related stores UNDETECTED, then the methods used are not resource hogs, nor did they invest that much money in the tools. Some times, you just got to stop whinin’ and git ‘er done! Share: