Mark Tiley

Common Technology Oversights Part 1: Data Security

Tue, 14 Jun 2011 15:03:00 -0500

Introduction

The first group of common oversights that I’ll be covering falls into the technology category. Technology is a bit of a broad area and you could, in some sense, group nearly everything being discussed in the next few post as “technology”. But, instead of overwhelming you with a seemingly never-ending list, I’ve done my best to group everything into what makes sense.

Data security is probably the single most important and unfortunate oversight that I’ve encountered, with “data backup” being a close second. What makes it even more unfortunate is that most people are aware of the importance of these two necessities, however, for different reasons, don’t thoroughly question vendors about them.

Don’t get me wrong; I’m not saying to distrust a vendor. You will ultimately get a sense from your dealings with them if they are trustworthy. What I’m saying is that a certain level of due diligence is required to ensure you are asking the right questions and making the right decisions. Just because a sales person says “Yeah, we take data security very seriously”, doesn’t mean her idea of secured data is compliant with today’s standards or that she even understands what her company does, or worse, doesn’t do to protect your data.

I’ve broken Data Security into three areas: PCI Compliancy, SSL and Data Encryption. This list could be much larger as security itself is broad enough to justify a series of article.

PCI Compliancy

PCI Compliancy is one of those things that you probably have never heard of before unless you have dealt with credit card processing previously. PCI stands for Payment Card Industry and is a collaboration of standards put together by the major credit card companies. PCI compliancy, in theory, encompasses all necessary non-physical security standards. In a nutshell, a PCI compliant vendor, has gone through a vigorous questionnaire and has had their servers and software scanned for vulnerabilities.

Surprisingly, I’ve only had one client in the past ask me if my company was PCI compliant. In fact, I believe it was the first question they had. Fortunately, the company I worked for was PCI complaint at the time*, opening the door for us to gain a great client and relationship.

When building your RFP and/or selecting your vendor, ensure you ask if they are PCI compliant. Also, don’t be afraid to ask for a copy of their PCI compliancy certificate that proves they are indeed complaint and not just telling you what you want to hear.

Please note, that if a vendor hasn’t gone through the PCI compliancy process, it doesn’t mean that they are not secured and that you shouldn’t use them. However, it certainly helps if they have gone through it.

*PCI compliancy does expire and it is possible to lose your compliancy if you do not continue to maintain your systems.

SSL

These days, most people know the importance of an SSL certificate when accessing a website displaying sensitive information. For those not familiar with it, here’s a quick summary: SSL stands for “Secured Sockets Layer” and it’s the culprit behind the “s” when viewing a website having “https” in front of it. When a website has “https” (or you see the little lock icon in your browser), it means that the information you are sending back and forth between your browser and the website’s server is encrypted.

What many aren’t aware of is that newer SSL certificates come with an option called “Extended Validation” or simply EV. EV doesn’t provide any additional level of encryption or security mechanism; however, what it does do, is validate the owner of the certificate as being “trusted” and “legit”. A website secured with SSL and EV will cause the address bar at the top of your browser to change color (most cases it changes to green). In most browsers, the organization owning the certificate will be displayed as well.

EV became a necessity due to the abundance of email scams and phishing websites that were trying to pry credit card/banking/social security information from unsuspecting users. These fraudsters would go as far as setting up fake websites with SSL certificates that looked legit. The idea behind EV is to filter out these fraudulent websites and make it harder to for them to look trustworthy.

Why is EV important when using third party vendor to host your registration software?

Let’s use the example of a fictitious association called “The National Association of Baseball Fanatics” (NABF). Let’s say they have a member named Joe. Joe gets an email about the NABF Annual Meeting. Inside this email, there is a very big “Register NOW” link and he decides to click it to attend. A new browser window opens and he is displayed a registration form that, well… looks something like the NABF site, but, it’s not. Joe then notices the address at the top reads something like the following:

https://nabf.best-reg-software.com or https://www.best-reg-software.com/nabf

Let’s assume that the SSL for “best-reg-software.com” doesn’t contain EV.

Thoughts in Joe's head:
“hmmm…. I don’t know…. I think I will call the association to ensure this is right” or “I’m just going to mail/fax my registration in”.

Now, I’m not saying that Joe would have been persuaded by an EV highlighted address bar and that he would have registered online, but he may have. The point is to make your users as comfortable as you can and to eliminate as many administrative registrations (mail/phone/fax) as possible. You want to get the less savvy users, who tend to be more comfortable using one of the administrative methods, to start using the online registration form. You also want to make the savvier users, who tend to be more technically aware and perhaps more paranoid, to feel confident in the registration site and process.

Like PCI compliancy, SSL with EV isn’t a necessity, but it doesn’t hurt. Be sure to ask your vendor if they use Extended Validation SSL Certificates when hosting your registration site/forms. Also ask your vendor if it’s possible for a user to log into the system (admin or public) without it requiring “https”. The answer to this should be “No”, but it does happen.

Data Encryption

When collecting sensitive information such as passwords and credit card details then storing it in a database, it automatically gets encrypted, right? Wrong. It’s up to the vendor to ensure data is being stored in a way that, if your data is accessed by an unauthorized set of eyes, it won’t make sense.

Almost weekly we hear about systems being compromised with Sony’s Playstation Network and Citibank being two of the more popular recently. In the case of Sony, the hacker apparently used a technique called SQL Injection in which he can manipulate input data (such as data being entered on a Contact form) and make it so the system provides data that it wasn’t intended to. Sadly, often this data is in clear text and readable to humans.

Clear Text = “Your Password”
When Encrypted = “rY6m2&ee$mJW2xh7R77tr00”

Never assume your vendor of choice is encrypting data and always ensure they are encrypting what you deem necessary. Most vendors know to encrypt credit card details; however, that’s often where the encryption stops.

Let’s use an example where your vendor is storing membership information such as member numbers and passwords in clear text. If this member data is accessed by a hacker, he could potentially log into your association’s membership system with any of these member records and view, edit or delete their data.

Be sure to ask your vendor if they encrypt sensitive data and if they can accommodate requests to encrypt specific fields.

There is much more to data encryption than I discussed that falls out of the scope of this discussion. Essentially, you want to know if the data is being stored safely. If you want to take it a step further such as asking vendors which encryption algorithm they use, all the power to you. The more you know the better.

Conclusion

To sum it up, we have to pay attention to the data security mechanisms our vendors are using. To help, here are the questions we want to consider asking:

Are you PCI compliant?
If so, can you provide a copy of your PCI compliancy certificate?
Will our site use an Extended Validation SSL Certificate?
Are there any areas of the site in which users can log in without it requiring “https”?
Do you encrypt sensitive data such as credit card details?
Can we request specific fields to be encrypted?

I hope this helps. Please don’t hesitate to contact me if you have any questions. Please check back shortly for the next post covering Data Backup oversights.

Common Oversights When Choosing a Software Vendor

Tue, 07 Jun 2011 16:50:00 -0500

I will be posting several “Oversights” articles in hopes that we can help remove the blindfolds and unlock those crossed fingers when it comes to identifying your needs and trusting that your vendor is implementing what is considered best practice or compliant technology, software and processes.

From my experience, everything comes down to asking the right questions. Simple!

In this context, miscommunication occurs when we don’t understand what is being done or what is needed. These misunderstandings occur when we don’t ask the right questions (or not enough questions). Why does this happen? Often we don’t ask right/enough questions because, well… we don’t understand enough about the topic to feel like we can ask the questions. Confused? It’s a vicious cycle and one that will lead to scope creep and Easter eggs*.

*Think of Easter eggs as a surprise that you stumble across when going through the lifecycle of your project. Unlike traditional Easter eggs (like the lollipop my daughter found this weekend inside an ornament that was left over from this past Easter), Easter eggs in a project tend to be something that surprises us in a bad way and expose themselves when we are least expecting it.

So, we want to make sure we have the right questions on our RFP. We want to make sure we can evaluate the responses to our RFP effectively. And, we want to ensure there are as few surprises as possible. For those who don’t use a formal RFP and instead rely on demos and past registration forms/documentation to express your requirements, these articles will be just as applicable. The same questions, whether formally written or informally asked, still need to be answered and understood regardless of your process.

The upcoming articles will be:

Common Technology Oversights

Part 1: Data Security

Common Software Oversights

Common Process Oversights

Common Feature Oversights

Here We Go!

Tue, 24 May 2011 12:15:00 -0500

I’ve finally managed to launch marktiley.com and thought I’d start my inaugural blog post into the world of event technology and software consultancy with a simple, yet enthusiastic, “Glad you made it!”.

I’m going to use this post to introduce myself to those who don't know me, as this site may result in questions such as “Who is this guy?” and “Where does he get off saying he’s a software specialist for the industry?” Well… I anticipated that and am going to take a swing at filling you in. Just a heads up, you may see the occasional reference to baseball in my posts.

Before I bore you about myself though, let’s start with this site and why it exists.

Do any of these sound familiar?

“Last year we did everything in Excel...”
“I really don’t know anything about registration software...”
“Can you tell me how our software should work?”
“We aren’t happy with our vendor. They just don’t understand our needs…”
“What’s the most efficient way to collect abstract submissions?”
“How can we expose our event to more people over the web?”
“Should we pre-print our badges?”
“What’s the difference between 1D and 2D barcodes?”

This site is a result of years helping many meeting professionals answer questions or work through issues like those above. If they sound like you, please don’t be embarrassed! You have enough on your plate planning and managing your events. It’s not only justified but expected.

For those who are more technically experienced, please note that the content on this site is geared towards those who are not, although, I hope the content is useful to everyone.

What is a specialist?

There is more to being a specialist in an industry than reading up on the latest and greatest then blogging about it. Don’t get me wrong. I do find different perspectives on emerging technology intriguing. In fact, I spend several hours a day reading them and I too will blog my opinions on these technologies.

I’m talking about actually understanding how this technology and software can be used. How it can integrate and interact with the existing solutions you already have in place. How this technology and software can improve your overall process and alleviate the manual and administrative tasks that haunt you!

Now on to me…

What makes me a specialist?

I didn’t wake up one day and say to myself “I am pretty good at this event software stuff” or randomly choose an industry to claim my stake. Honestly!

It’s the result of years of hard work, trial and error and learning about the challenges faced by meeting professionals. It’s the result of working with these fine folks and helping them improve not only their software systems, but their processes.

Most of my involvement has been behind the scenes, developing and delivering event management products for countless associations, corporations and event management companies. Now I intend to come out of the woodwork and share my knowledge with hopes to help better inform you on how to get the most out of the software and technology available to you.

My Experience (short and sweet)

I’ve been involved in the event industry for several years now and even longer in the world of software development. I’ve been involved at some capacity in events and registration software for the past four positions I’ve held, including my own software development company 6 years ago.

I’ve had the pleasure to operate in such roles as Systems Analyst, Project Manager and Software Developer as well as manage, lead and mentor several great teams.

For the past 5 years, I ran the operations, development and IT for an event registration company in which I co-founded. Here, my main responsibilities were the analysis and delivery of our products and leading our great operations staff, whom I miss extremely.

Why am I doing this?

To help end the world of bad event software experiences!! Maybe a bit dramatic… but you get the point.

I’ve seen and heard stories about vendors who simply quote and build software without asking 5 simple words… “How are you using this?”. Seems obvious right? Well, that’s not always the case. Often systems will get built by a team who don’t fully understand how it is going to be used or what the client is expecting. This may be the cause of the client not expressing their needs or possibly the vendor not asking the right questions.

Whatever the source of the challenge may be, it can be eliminated if you understand what you need and how all the parts fit together. This not only prepares you with what to expect, but loads you up with all the right questions that NEED to be asked when defining the scope of your system with the vendor.

As time goes on, I will post more content, links, tools and resources that should help when choosing your next software system. In the meantime, if you ever have any questions, please contact me.