Security and Compliance in B2B eCommerce

Joseph Kirkpatrick: Yeah, I'm really looking forward to talking to you guys and talking through this important subject with you.

Jary Carter: Yeah, it is such an important subject and it's becoming increasingly important, seemingly in recent years, I would love to just get into introductions around the two of you. I'd love to just understand how you got into the space, a little bit of your background, from your own perspective. You both have wildly impressive bios. Let's just start with you, Jeff.

Jeff Man: Sure, thanks, Jerry. I'll try to be concise. It's compressed 40 years into 90 seconds or so. Primarily, I got my start in information security working for, as you mentioned, the Department of Defense, and my first real job was as a cryptographer for the National Security Agency, which of course, protecting communications and information. I was there in the mid-80s to mid-90s. So sort of at the cusp of when the internet was becoming at least publicly available and caused the explosion that we know now today as the digital world, what we call cyber.

Then I shifted over into cybersecurity, although we didn't call that at the time, in the early 90s, because I was working with a small group of guys that were looking at how to break into computers and networks because they were becoming more of a thing. And you know, we'd all seen movies like war games, and sneakers or hackers. And we're like, that's kind of cool. We want to do that. So I ended up looking back on it and can say that I was a founding member of the first NSA red team and went out into the private sector shortly after all that happened. Primarily trying to help companies of all sizes, shapes, and forms figure out how to connect to the internet in a secure way.

Somewhere along the line, I fell into the PCI payment card industry. It came out when the Data Security Standard came out in 2004. It was handed to me by a boss back in 2004. And he said "Here, read this, we're going to do it." I read it and I said this kind of makes sense. I've been doing it ever since basically. So you know, I can wrap up the last 15-16 years by saying I've been a QSA, working with hundreds of companies of all shapes and sizes. I help them understand how to do basic information cybersecurity, given their environment, their vertical, and a certain set of requirements that they're bound to if they want to engage in commerce, at least with credit cards. So that's me in a nutshell.

Jary Carter: That's great. You have such an interesting and rich background. I'm excited to ask some questions about that today. oseph, we'd love to hear your background as well, if you wouldn't mind just giving us a little bit of a thumbnail sketch of how you got into where you are and what you're doing now.

Joseph Kirkpatrick: It all started for me in 1984. And 1984 was the year of the computer. It was the timeframe when the IBM CEO said that no one would ever want a computer in their home. And the personal computer was the Man of the Year for Time Magazine. So that was the year that my parents sent me to a class on computers, they were very forward-thinking, and I was 13 years old. And, you know, I just decided, wow, I want to work with this.

So when I got out of college, I did systems engineering work. We were installing Windows for Workgroups for companies who were converting from Novell. And I worked in systems engineering for about 12 years, and was doing that for banks. And being a highly regulated space, they started coming to me with questions about satisfying these different compliance needs and satisfying the bank examiners on the different things. And they started asking about data security.

And as a result, we did risk assessments and penetration testing, and help them write their information security program. And once I got involved in that, and got a taste of that aspect of things, I decided I really want to specialize in that area. And I saw the need for it and the importance of it. And that's really what got me focused on cybersecurity.

Jary Carter: I remember seeing hackers in the movie theater, Jeff, which was like such an iconic movie for me, Joseph, my first job was at Novell. So my very first tech job, right out of college was at Novell. Going into computer class, your parents really were forward-thinking I think that was not on most people's radar, sending their kids to computer class. So very, very cool.

Let's jump into today's topic. There was a question before as we were preparing around compliance and security. Are they the same thing? What is the difference? Jeff, would you like to unpack both of those for us and the differences?

Jeff Man: Well, it's one of those questions where you ask 100 professionals, you're gonna probably get 100 different opinions. So this will be my take on it. There is a misconception that compliance does not equal security. And the perception that compliance is just kind of a silly nuisance exercise. It's not real security. And it's not reflective of all the things that the security people do within organizations. And so it's viewed by sort of one camp is something that's very simplistic and very checkbox oriented, you're not really proving that you're doing anything, you're just saying that you're doing stuff.

Now flip that around, I've worked with companies for almost 20 years, trying to follow this silly little list of over 400 specific requirements, that you have to do every one of them. And companies struggle to meet every one of these requirements. And they struggle to consistently meet the requirements. A lot of the requirements, a lot of security in general, have to do with continuous processes doing things on the regular, which feeds to this misconception between security versus compliance: compliance is a one-time & once a year, "come in and see how you're doing" kind of thing and security is something that you do all the time.

Well, a lot of PCI requirements are about if you are doing this thing daily, weekly, monthly, or eriodically, so it's meant to be reflective. So that's my sort of backdrop.

Security is doing a whole lot of things to try to either prevent bad things from happening to your organization, or detecting that something bad is happening to your organization, and hopefully minimizing the damages. Compliance, in that context, is simply a measuring stick, a way to evaluate or assess how well you're doing all these basic security things. So to me, compliance is just a reflection of security. They're kind of one in the same thing. But that's my silly little opinion.

Jary Carter: Not silly at all seems very well thought out, and well articulated. And I appreciate that perspective. Joseph, in the spirit of compliance, you're an expert in this, what compliances are usually required for a manufacturer or distributor to be selling online? And when you go into a company and talk about compliance, what are the things you're looking for?

Joseph Kirkpatrick: Yeah, so if we're specifically talking about a company that's moving online maybe they've had a traditional brick and mortar environment, they've had a distributor model, but now they're moving into the online presence and starting to engage with people in other states, other countries, all those kinds of things. Very quickly they get swallowed up with all the compliance requirements, most people dive right into offering those new services or doing business online.

And there's a reactive sense of responding to things that a customer might ask or a regulatory body might ask. Speaking in the year 2022, I think privacy is at the forefront, if you are moving to an online presence, if you're starting to serve people who are in different places, you have to be aware of the laws that are relevant to where your customer bases. And so if you've got a customer in California, you have to be concerned about the California Consumer Protection Act. If you are working with a client who is in Europe, you have to be concerned about GDPR.

And so one of the things that a company has to do when they're making that change is they have to have a program to understand what data are we collecting from people? What data do we have to maintain? How long do we maintain it? What is our policy on doing that? Do we give access to that data to the people that it belongs to, such as the consumer? Who in our organization has access to it? Is there a right for them to have access to it?

There are a lot of things to think about in terms of the data that we collect in the eCommerce world and then what we do with it. Can we use transactional data when we make a sale to someone? Can we use that now to market additional things to them? There are laws around that. But also, can we share that data with another business unit or another entity that our company owns, or a third party that we work with? So these are all very important questions to ask that are really derived from a lot of the compliance frameworks that are out there.

Jary Carter: This is the current state of affairs in enterprise tech security, but what are the biggest trends? What do you see, Joseph?

Joseph Kirkpatrick: 10 years ago, I thought it couldn't get any better in this industry. 10 years ago, I thought well, we're at the peak. But I'll tell you that it's never been more exciting. But a lot of that excitement comes from really bad things happening.

If you follow all the releases that come out from government agencies, from industry groups, it's impossible to keep up with the breaches that are occurring, the vulnerabilities that are being discovered, and the threats that are no longer for the military or the government to be concerned about. It's just really hot and heavy right now.

With every release, it's something that has been exploited for an amount of time that we didn't know was being exploited. And so now we have to check our systems and the third party that we have a relationship with and technology that we have in place over here, we have to check to see whether we're exposed because of this thing that has just been revealed. So it's just a constant revelation.

Today, it feels like daily about the unknown, something that we couldn't have foreseen. As organizations, we don't need to be reactive to that. We need to be planning for how do we respond when we become aware of some new threat that has been published or reported.

Jary Carter: I really appreciate that perspective. Jeff, I'd love for you to weigh into this as well. What are some of the things that have you excited about the current state of enterprise tech security?

Jeff Man: Well, I don't like to think that I get excited about any of this. I'm sort of everything that Joseph's excited about, I find it depressing.

Jary Carter: But now we know the optimist, and the pessimist.

Jeff Man: It's interesting, you brought up this analogy of the autobahn and casually mentioned that everything seems to be reactive. But that's really the essence of security is that we learn from previous mistakes, we learn from bad things happening. I can remember when I first read the PCI data, Data Security Standard, the 400-some odd requirements, I was like I know why this rule is there. It's because this happened. I mean, virtually every single requirement was in there at the time because it was trying to cover the bases.

I see a lot of tension. In our world, there are competing forces. Maybe I get excited when I can sit with a client and try to help them get to the point of understanding why do we have to do all this stuff? It's doesn't seem to make sense.

Since the dawn of us emerging into this electronic digital cybersecurity internet world, there's been a belief by consumers, let's say, including organizations, that security is something that's going to be taken care of by somebody else, the technology should solve everything, the technology should be secure. We shouldn't have to worry about it.

And if you talk to anybody that's been around this industry, you'll very often hear stories about the weaknesses. The things that cause companies to get breached very often are not so much the technology in and of itself, it's the way the technology has been misused, and misconfigured by users.

I think it is fascinating when organizations get breached, and we see them in the headlines very often, we always love to beat up on these companies, because they didn't have good security practices. They weren't doing the right things, there was this inherent weakness. And we seem to forget that, at the end of the day, they're a victim of a crime; somebody committed a crime against an organization that put them into this situation.

So this concept that there's responsibility for achieving a certain level of security, it's called Safe Harbor, that gives you some reasonable amount of security. But security breaches could happen to anybody. That hasn't really changed over the years other than there's less idea of Safe Harbor and there's more and more beating up on the poor victims.

And very often, it's legitimate, because either they've completely missed the boat on their employee awareness and having the culture of security, knowing what you can and can't do in terms of your business processes and your daily job versus that expectation of security being somebody else's responsibility within the organization.

So what excites me is there's this never-ending tension. And there's this need to try to open people's eyes or pull the wool off some people's eyes, depending on what analogy you want to use to just try to promote a better understanding of what's at play here. What's involved in terms of securing an organization or securing data these days?

Joseph Kirkpatrick: I love this. Because there is this just strong desire for people to pass the buck on security, and they don't want to feel responsible. It's just a strong desire that humans have to know that somebody else is responsible for this.

They feel unprepared, they don't have the knowledge, they don't have the skills to confront this growing complicated threat. And so they just want somebody to be responsible for it. And so some of the common things, I'm sure Jeff sees all this as well, but you go to an environment, oh, we moved everything to this cloud provider. And now they're responsible for security. We have this relationship with this managed security company, and we've signed a contract with them, and we pay them X amount a month, and they are responsible for our security.

And they just want that to be true, so bad. And the truth is security is such an important issue that affects your business, you're always responsible for it. And then you have to manage these relationships that are impacting the issue, and that are critical for the issue, but you just can't not be responsible for something that's so critical to the success of your business.

One time, this was just something that stuck out in my mind. I was doing an audit for a company in Minneapolis, and this was a big company. And I was going to be there for a week to perform this assessment. And for every question that I asked, the answer was, we have this service provider that does that for us. We have this service provider that does that for us. And so that's what the entire first day was. The first day it was we don't do anything with that because the service provider does that.

And so finally, at the end of the first day, I just said "Sounds like we need to talk to the service provider about all this because you don't have any of the answers for what I'm looking for."

And so we decided to get on a plane and fly from Minneapolis to St. Louis because that's where the service provider was. And so the next day, we had a meeting with the service provider, and I started walking through this issue. And to every question, they said, "Well, we can do that for them. But no one has asked us to do that."

Then the customer was saying, "Oh, I thought that you were doing that, I thought that you were monitoring our firewall." "We offer that. But no one has instructed us to do that. And you haven't told us what you want us to monitor. And you haven't told us what you want us to do with the thing that we are monitoring." That was a long time ago.

But that thing still happens today, especially with the cloud providers. People make these assumptions that the cloud providers are responsible for all of these things, but they're not, unless you take responsibility for establishing the policies, enabling the controls, assigning responsibility for people to monitor these things, and take action whenever there is a finding that happens. And so there's definitely this huge desire to relieve yourself of responsibility in this area.

Jeff Man: Well, if I can dovetail on that, I  think what you're saying, Joseph, is that the services are available. What you're not saying, but should be obvious to everyone, is that it comes at a cost. You have to pay for it. And there's an aspect to all of this, where maybe we should bring it up a little bit more, is that security and all the things that you have to do associated with security, regardless of the compliance standard, cost money. If not in terms of product and technology, then in terms of time and resources and training, and personnel assigned.

The early selling point of the cloud, was that we'd got all this covered for you. But if you read the small print, they were covering, what we used to refer to colloquially as lights and power. They were a data center that was hosting servers, it was in the magic wiffle about some of the cloud. But all they basically provided the security for was the physical security of the systems wherever they were.

That was 10 years ago. Nowadays, they have full-blown programs, they've got services for virtually every security requirement you can think of, from scanning and monitoring, and testing and access control, multi-factor authentication, you name it, they've got it. But it all comes at a cost. At the end of the day, maybe the best way to explain to clients in a language that they can understand is security comes at a cost. And you have to figure out how much you want to spend, where's the right way to spend it, and where do you make your investments.

Of course, then you have all sorts of solutions out there that are telling you how you can increase your ROI and make security part of your profit center. I'm not gonna say I completely disagree with all that. But you should be aware that security comes at a cost, so figure out where you need to spend the money, figure out the right mix, and figure out when it's cheaper, and more cost-effective for you to do it, versus a third party. But for God's sake, make sure that a third party is doing it for you, as Joseph was alluding to.

Joseph Kirkpatrick: When I see these providers, and these tools, use the same marketing hook, which "we will make it easy for you," I always shudder at that. Because the reason they use that in their marketing is that it works. You know, people want that to be true, so bad, you know, everyone Oh, good, I can sign up for this. And then it will be easy.

That's a strong selling point, but the truth is the things that you then have to engage upon and ensure that the provider is doing this, all this ultimately has to come from you. It is a difficult thing.

But the truth is sometimes a good security partner is going to bring things to you that are hard issues, and they're going to talk to you about things that are difficult, and to ignore those things might be easy for a short period of time, but a good security partner is going to bring some very challenging things to you, and then they're going to work through those challenges together.

Jary Carter: Before we get to maybe some of the outside questions, let's share any horror stories from your previous experience of failed security, costing businesses revenue and reputation. I would love to get your all's perspective on that.

Joseph Kirkpatrick: Yeah, we are usually in the line of fire in terms of being contacted by someone who has just been surprised with something and they're needing help. And so the most recent one for us was a farm supply organization, they traditionally had been a locally focused supplier, and they were moving online. And so this was a huge undertaking. For them, it was critical to their mission, critical to their strategy in order to get this up and running.

And they worked really hard, spent a lot of money and time on developing the eCommerce platform, and they were planning on having a much greater reach. And so the time came for that to roll out. And they were unable to get cyber insurance. That was a shock to them. Anyone who's been dealing with cyber insurance, you've noticed that it has changed, there was so much that was impacted because of ransomware. The cyber insurance policies have all been rewritten.

So now they're having to go through all these things that the insurance provider is requiring, like have you had a risk assessment; do you have endpoint protection; are you doing security awareness training? It's that compliance list that we talked about earlier.

And the truth of the matter was, they weren't doing those things. And so they couldn't get the insurance, and so the huge impact on their bottom line as a result of not considering the impact of security and compliance to this very important mission that they had as a business.

Jary Carter: Yeah, great example. Jeff, do you have anything you would add?

Jeff Man: I've got a million of them. But let me share two. One is more of a generic, something I see very often these days, especially since we're supposed to be talking about B2B, which in a PCI context is third-party service providers, people that are sort of in the middle between a retailer or a merchant and the back end card companies, banks and things like that, especially in an eCommerce context.

We've been talking about outsourcing and putting stuff in the cloud. I see very often these days a scenario where you have a retailer or a merchant that wants to do eCommerce and so they have to have a website. But they don't have developers. So they go to a third party to create the website for them. Of course, there are companies out there that specialize in that.

They also need to host it somewhere. Now, it's more common to put it in the cloud somewhere. But it's very often not the merchant that's engaging with the cloud provider, it's one or more of these third parties. So if you buy something online, and you go to the checkout page, where you're eventually going to put your credit card in, very often that's a completely other company.

So you've got in this scenario when there's a breach with the merchant, they are the ones that are still to be reporting PCI compliance. And they say, well, we don't do that we have this third party. And then that third party says, well, we don't do that we have this other third party.

I have this strong belief that things aren't getting done from a security perspective, because everybody thinks somebody else is doing it. So that's one scenario.

The second one is more of an application of the Lessons Learned type of thing. I had this situation with a client just a couple of weeks ago, I was doing an on-site assessment, going through all the different security controls. One of the controls in PCI is that you're supposed to monitor periodically, for the presence of any kind of rogue wireless access points, or any rogue devices on existing wireless networks.

This particular company had technology in place that, rather than doing it periodically, once every 30 days or 90 days, they're doing it basically real-time, they've got sensors that are up and running. And just part of what they do in terms of creating a wireless environment is to continuously check and report on any presence of unknown devices or any rogue devices.

Sounds great on paper – like, wow, you're just blowing the doors off the requirement, you're going way beyond the bare minimum. So the issue I had, though, was we were doing site visits of different retail locations. And this one particular site that we visited, the particular device happened to be unplugged. And so I asked a question, why is this unplugged? Two weeks into it, I'm still waiting for the answer.

But the bigger question I have is not why it was unplugged, but why wasn't your whiz-bang reporting mechanism identify it? Flagging or alerting the fact that sensors dropped?

So I mean, the lesson learned is, it's not enough to just simply put the technologies in place. You also have to know what to do with the results and the outcomes and know when something weird happens, so you can respond to it. I don't suspect that it's any nefarious activity. But I do question how well they've embraced the procedural process aspect of security, when they're allowing the technology to do what it does. And it seems like they're not paying attention to what it's producing in terms of output. So I share that as more of a very strong nudge, to think about how you implement a lot of the security solutions that are out there.

Jary Carter: Yeah, it's interesting. One of the things I'm hearing is don't actually look to your third-party vendors as a panacea for your security and compliance. You've got to take responsibility for the security needs that you have as a business. Did I catch that? Any final thoughts you have?

Joseph Kirkpatrick: That's not where the assurance comes from, you know. The assurance comes from a product that you use, or a provider that you have a relationship with, you're responsible for this thing called security. And it's something you're always pursuing, but you never actually arrive at it, you can live in a state of security, and you can feel like you're experiencing it, but you have to be ever vigilant, and you have to always be pursuing it.

I love what Jeff pointed out. They divided responsibility into so many different pieces. So when you come in, and you want to look at things in context, and you want to look at this piece, and that piece and that third party, the response you always get is, "Well, we don't want you to look at that, because that's not in scope."

When you hear that, you're just like, Ah, it is in scope, your security is always in scope. We shouldn't be slicing and dicing it. And so yeah, I'm glad you picked up on that, because it's definitely a huge concern of mine as well.

Jeff Man: If you think of security as a burden, you've already lost. What old timers like us try to do is just educate and give companies context and help them understand you really can't outsource security. You can outsource the activities, and you can outsource some of the specifics. But responsibility in that overall, comprehensive backward look at how does this all work together – that's very often lacking.

There are not enough people like us to do the auditing and assessing that seem to embrace the fact there's something wrong here because nobody's taking that big look, until something bad happens.

And when something bad happens, the people that are going to come and find whose fault it is. It doesn't matter who you claim is supposed to be doing it for you. It falls on you in terms of liability. And again, that's a dollars and cents type of thing. It's an economic decision.

Don't think you're selling yourself cheaper or being economical by pushing stuff out to a third party, because they claim they've got you covered. You make sure you consider all the costs, and you can outsource perhaps the responsibility, but that doesn't mean you've outsourced the liability.

Jary Carter: We're going to end on that quote because it was very good. It actually encapsulates the eCommerce security conversation that we've had here today. I want to thank you both, for coming in and lending your perspective, and for sharing your expertise. Today's conversation has definitely lived up to the brand of B2B Commerce UnCut. Nobody's trying to sell anything except for the fact that we want to keep you all safe as you engage in eCommerce out in the market.

Thank you both so much for your time today, and thanks, everybody, for tuning in.