Automatically transcribed, so names and technical terms may be misspelled. The audio is the record.

The Colorado Equals Security Podcast is your local source for regional security news, local events, and interviews with key individuals in the region. Now here are your hosts, Robb Reck and Alex Wood. Welcome to the April 17th, episode 11 newscast for the Colorado Equals Security Podcast. This is Robb Reck. And this is Alex Wood.

We're here coming to you from the basement here in Centennial, Colorado, here to talk about some, some fun activities in the security community. But first, it's Easter today, Alex. Happy Easter. It is Easter. Happy Easter.

Did you go find some eggs this morning? We did some eggs yesterday, and then this afternoon we'll have another round of eggs. Very nice. Got some friends coming over. Nothing like some Easter eggs.

So it's pretty springy this weekend. You do anything fun? So, well, it was actually my birthday yesterday, so that was fun. Went out and had a nice dinner. We also had a number of kids' sporting activities, a soccer game and a football game, all that kind of stuff.

Happy birthday, Alex. Thank you, Robb. How about you? We also had a— we were talking about earlier, we had a soccer game, my son's first soccer game, and I had the joy of watching him score his first goal in his first game. And that was pretty exciting.

So I was annoying dad yelling, cheering, and running alongside the field with him and, uh, hopefully urging him on to victory, which, you know, he had a good time. Premier League, here we come. Here we go. Uh, why don't we go ahead and dive into the news here? Um, first thing we want to talk about this week is a couple of regional bits of news.

Number one, Colorado is the number 4 state in the country for venture capital funding. Yeah, so in the, the first quarter of this year, it looked like we had a bump up of Uh, spending in that area. Some of it was, was some of the, uh, the deals we've talked about previously with, uh, Surewell and ProtectWise being 2 big ones. Um, but I, I think it's a good sign for Colorado. Um, it looked like previously we hadn't been above, you know, 6 or 7, so getting up to number 4 is really cool.

Yeah, you know, this is one of the, one of the missions for us, right? We want to bring in jobs and talent and funding to help these companies get started in the area. So it's, it's a neat thing to see. Um, obviously, you know, there's a long way to go, but, uh, pretty cool to be number 4 here. Yeah.

And then, uh, sort of similar to that, the next story on the list, uh, Denver was the 2nd most attractive city for tech jobs. You know, looking at that story, it focuses a little bit more on developers, but, you know, I think that they title it a little more broadly. Yeah. And it's, it's definitely interesting for us in security, as you know, all of the technology is gonna, is gonna be dependent on developers. It looked like the 2 key data points they were using for this story were average salary and cost of living in the area.

That seemed like, or at least 2 of the big input. Yeah, exactly. One thing that I noted was that, you know, to live comparably in San Francisco as Denver, you needed to make $69,000 more in San Francisco, which is pretty incredible. Basically 50% more because the salaries were at like $112,000, I think, as an average salary for a developer in Denver. So number 1 on the list was Austin, Texas.

Uh, where, where the salary was a little bit lower, but the cost of living was quite a bit lower. Exactly. Uh, so we also wanted to point out kind of a neat thing that happened this last week is Optiv was named LogRhythm's Partner of the Year. Yeah, I think that's cool, you know, seeing 2 Colorado companies working together really well. Um, LogRhythm obviously making, um, SIEM products and, uh, and Optiv selling and doing managed services and consulting around those products.

So in the— for those who aren't real familiar with the vendor side of things, a vendor's partner, basically what they're saying is you're the, you're the guys who sold the most of us, or, or who we liked having sell our stuff the most. So pretty neat, you know, a couple of local companies working together and hopefully making each other more successful. Exactly. Uh, also, um, Optiv, another news story with them. They appointed former RSA senior executive David— excuse me, David Castagnola.

Castagnola— sorry, that's a tongue twister— as Executive Vice President of Worldwide Sales. So I think that's interesting in the worldwide part there, um, you know, Optiv potentially trying to make a bigger name for themselves, um, outside of the US. Yeah, presumably part of the investment thesis when KKR, you know, acquired a majority stake in them was, um, was that they could, they could expand their market, get outside of the US, and Looks like they're actually, you know, taking some steps in that direction. David Casagnola was the senior executive, like you mentioned, for RSA, and he's out in Boston. Hopefully he's gonna help them get some of that expertise getting outside of the US.

So Gary Hayslip was named CISO for Webroot. I don't know Gary very well personally, but he certainly had a name in the industry over the last couple of years. Been, been very influential as his— as the CISO for the city of San Diego. Yeah, and I don't know him really well either, but I was at a dinner with him once. Seemed like a very nice guy, very intelligent.

Um, yeah, he also put out a book recently, uh, The, The CISO's, uh, Desk Reference Guide, I think it's called. Yeah. Um, which I have but have not read yet, but does look interesting. Yeah, so, so hopefully, you know, congratulations to Webroot for, for getting one of the, the larger name CISOs from around the country. And hopefully that's going to help them both build out a program and, you know, talk about that program larger.

Now, their headquarters is in Colorado, but I think that their CEO lives in Los Angeles, if I remember correctly. So my guess is that Gary's probably not moving here to Colorado as a part of this. Seems reasonable. There's actually a couple of stories in the show notes about this, one that's the press release and one that's an interview. Um, you know, Webroot is, is trying to make a push in, uh, the area of IoT.

And, uh, when Gary was at the city of San Diego, he had a big interest there. They were doing some smart city, uh, things in San Diego. So that, that seemed to be like a reason for him wanting to go to Webroot. Yeah. Speaking of IoT, ProtectWise has hired a VP to lead up their industrial IoT practice.

Uh, that seems pretty cool. Um, I'm not sure that I understand the difference between IoT and industrial IoT exactly, but, um, I guess it's just more focused. Well, it might be. You tell me, if you were a decision maker in IT for an industrial control company and you saw— and you were trying to choose which product to go with, would you buy the one that said IoT security or the one that said industrial IoT security? Let's see, I think I would say industrial, but this seems to be like like instead of calling it industrial IoT, this is really just OT, operational technology, and maybe just a rebrand there and, and moving it forward in that direction.

Anyway, interesting stuff. Good to see ProtectWise making some moves in the IoT space as well. Yeah. And then, uh, also Managed Methods, we've talked about a couple times. They're that CASB up in Boulder, right?

Yep. Uh, they joined the AWS Partner Network. So, uh, that doesn't seem like a huge surprise to me. They're, they're a cloud security vendor. AWS is the, the gorilla in in cloud, so you probably want to be in bed with those guys.

I will say though that the first iteration of CASB didn't really have much to do with AWS. It's really been more focused on, um, you know, your box.com, your, your Salesforce, the other traditional, uh, software as a service. Yeah, for sure. Offerings. And AWS really gets more into infrastructure and platform as a service, which is a, you know, a whole new iteration for them, I'm guessing.

Yeah. Yeah, nonetheless, it is good to see those guys partnering up. Yeah. Last thing in the news section I wanted to mention is I did include a link to a GDPR mind map made by Javad Malik, who's a friend of ours out from, from the UK. This is just an interesting reference for you to look at to help understand what are all of the different requirements that you have based on GDPR, kind of in one nice image format.

And Robb, why would we care about GDPR? Well, we are a little bit later in the episode going to go over to a feature interview where we talk a lot about GDPR and understand what are your requirements as a result of that coming regulation. If you are listening to the podcast right now thinking, I don't care about GDPR, it's not interesting to me, you might want to listen at least for a little bit and understand that it actually might be relevant to you after all. Cool. So that's the news.

Let's talk about some events. So coming this week, We've been building it up for the past, I don't know, month or so. But the ISSA Women in Security SIG first meeting is happening on the 19th. Very, very big event. Yeah.

So we've been telling you guys to register for the last couple of months, and now we got to tell you, sorry, you missed your chance. We sold out. I think we got to 125 people and realized that that was about all that the venue could hold. Um, hopefully you guys got, got in there. If not, there's going to be another Women in Security meeting coming.

I think it's in late June. That should be posted here pretty soon. Um, but anyway, looking forward to that on Wednesday. Uh, also Wednesday, the same night, the OWASP monthly meeting is taking place. That's at Dave Buster's near Colorado and 25.

Uh, and who'd you say is speaking this month, Alex? I think it was— didn't you say this CTO of Cloud Passage? That's right. Yeah, CTO of Cloud Passage is going to be talking there. And that should be interesting as well.

And on the 20th, the ISACA monthly meeting, they are having Tanya Bakam. She's a SANS instructor, and they're going to be talking about auditing mobile and web applications. So if you're interested in a little bit more technical for an ISACA meeting, that should be a good one. So that's Thursday afternoon. And then Thursday evening, SecureSet has a threat research and network forensics training with Anthony Casa, who's a Palo Alto employee, Palo Alto Networks employee.

And then also on Thursday evening, there's an ISSA happy hour downtown. So if you want to go learn something about network forensics, go to SecureSet. If you just want to drink yourself into oblivion, ISSA downtown happy hour. Exactly. So that's, that's it for the events in the next week.

You know, we do want to touch on RMISC briefly. We talk about that every week, but this week we thought it would be kind of fun to just you know, take a look through the courses and maybe share with you guys, uh, a training that we're interested in specifically. Yeah, so, uh, one of them that I thought looked interesting, um, it's on the, the first conference day, Wednesday, um, in the late slot. It's called Effective Guide to Vetting Threat Intelligence for Improved Operation. Uh, this is by Tom Hagel of, uh, ProtectWise.

Um, you know, I, I've often seen threat intelligence as, you know, a bit of a snake oil Um, just that, you know, it's good information, but you often— doesn't really help you any. Um, so, you know, thinking about vetting and, and how, how to find the best of threat intelligence, uh, to actually make it useful for you, I think is an interesting idea. Yeah. And the one I, I pulled out that I wanted to mention is, is on, uh, Thursday at 3:15, which is the late, the late slot on the second day. It's called How to Make Security for Microservices Easier Than Herding Cats.

I think microservices is where the world is going. If your IT department's not going there yet, they're going to be going there soon, and having a strategy for how we secure those things is going to be challenging because it's really a different way of making applications. Of course, also on Thursday at 11:15 is the Colorado CISO panel, which we're both involved in. Everyone should definitely go see that. Anyway, looking forward to that.

Then of course, we have our RMISC is May 9th through 11th and registration is up right now. The 12th and 13th directly after is Denver B-Sides. Hopefully you guys can make it to both. If you can't make it to both, you know, think of RMISC as probably the one with the, the broader range of different types of tracks, but Denver B-Sides with the more beer. Right.

And B-Sides obviously lower priced and more casual. Yeah. And they're both great. Hopefully you can make it to both. I'm gonna try and make it to both myself.

Great. So that's the events we have. Moving on to jobs. Top of the list, hosting.com is looking for a CISO. Yeah, I think we've, we've talked about there a little bit before.

Our friend Johan Hybnet we mentioned was moving out of state and leaving that job. The position is now posted and available for you to apply to it. The city of Lakewood is actually hiring a CISO as well. So if you're interested in leading a program for public sector, that'd be a good option for you. Yeah, so next, uh, State of Colorado, uh, the Division of Higher Education, they're looking for an IT security and compliance lead.

Do you know if this is working with Debbi Blyth over there, or is this kind of working for someone underneath her somewhere? You know, I don't know if it's directly involved with Debbie or not. Um, this is actually, uh, I believe for the, uh, the College Invest service, um, you know, so the 529 plans in Colorado. So it'd be helping to protect the money that all of us have put away, hopefully for our kids for college. Yeah, if you, if you don't do your job well here, and then I'm gonna have to explain to my kids why they, why they can't go to school.

That's right. Verizon is hiring a senior IAM security architect. Uh, DataRobot, which I believe they're in Boulder, they're looking for an information security analyst. I thought that was interesting because, uh, DataRobot is a big data company. Um, be— the company itself looks sort of interesting.

They actually had a couple other jobs open as well. And the posting says, jumpstart your career in data science with the world's most advanced machine learning platform and accelerated training program. So it looks like maybe a marketer wrote this job description. Not sure about that. Uh, Charles Schwab— I, I put this one in here.

Charles Schwab is hiring an Archer administrator. So Archer is the big GRC platform really kind of the central management for your security and compliance programs. And they're looking for someone to help run theirs. And if you're good at Archer, then you can probably write your own check. So yeah, Experis is hiring an IT auditor.

ViaWest, you know, a big Ping Power Pipe kind of company here in town, looking for a security engineer. Layer 3 TV, I don't know Layer 3 TV, but they are hiring a senior security engineer, on, uh, network and systems. Yeah, they bill themselves as a next-generation cable company or something like that. Sounds like an online TV provider. That's pretty neat.

And they're here in Denver? They are. Very cool. And then CenturyLink is hiring an intern in their corporate cybersecurity area. I assume that this is working with Dave Mahan over there.

Anyway, good opportunity to get into CenturyLink for sure. Well, with that, I think we're done with our newscast for this, this week. We are going to go over to the feature interview, and I want to make a recommendation. In the show notes, we have a link to an outline that kind of walks through GDPR. It was created by Jim Keese, who's, who's about to talk to us in this feature interview.

You might want to either take a look at this outline as we go through the interview, or later on if you want to refresh yourself on, on the GDPR requirements. It's a good resource, and definitely appreciate Jim's time educating us, and of course Steve Edmonds' time as well, who sat down with me during this interview. Hopefully you guys will get some good stuff out of that. With that, Alex, anything else you want to say before we let people go? I don't think so.

Have a great week, everybody. Great week.

Hey, this is James Carder, CISO at LogRhythm. This is Colorado Equals Security for Colorado security professionals by Colorado security professionals.

All right, well, this This is Robb Reck, and we have a very special feature this week. We're going to be learning about GDPR from a couple of experts on it. So, I'll let the panel here introduce themselves, but hopefully over the next half hour we have a chance to get to learn quite a bit about what GDPR is going to look like and what it is. You want to go ahead first, Jim? Sure.

Jim Keese. I'm with Privacy International LLP. It's a small niche consulting firm. We focus on data protection, information protection, governance, data privacy on a domestic and international basis. Really helped a lot of major clients.

I've had a lot of major clients that I can't speak about right now. But prior to that, I was the Chief Privacy Officer for Western Union. I was recruited by Western Union to actually define, start, and roll out their global program. So we went from ground zero back in 2006 to where I left in 2014. 2015, in turning the program from ground zero to basically a fully operational program.

And prior to that, I was the CPO CSO at Eastman Kodak. The Chief Security Officer? That was dual, yeah. So at Western Union, you worked with Mike Kalac pretty closely? Oh, I know Mike very well.

Very fun. His golf game's a little better than mine. I don't know what that means. If that means he spends less time working, I'm gonna call him out for that. All right, well, thanks, Jim.

Stephen, you want to introduce yourself? Yeah, I'm Stephen Edmonds. I'm Director of Governance, Risk, and Compliance here at Ping Identity, and I work mainly with the sales team and the compliance teams to make sure that we're meeting all the requirements that our customers have and also making sure that we're meeting the applicable laws around the, the world when we deal with our data for our customers. My history is I spent about 7 years as an independent contractor working with companies, helping them become SOC compliant and, and start the first step down the compliance path. That's usually the first place that they start, and I come in and help them layer in controls and start setting up a direction for their company and what they're going to do with their data.

So it's just obviously we work really closely on making sure, you know, we understand the requirements from the compliance frameworks and then layer them in security or other processes, and your team is instrumental on that. So this, the whole topic of GDPR, which maybe, Jim, I'll let you explain the acronym and go into more detail, but this topic was, you guys brought it up, you brought it up as an idea for a show, and it was, it really appealed to me as it's something that I know Ping Identity, I'm personally having to deal with, and Steven and I just earlier today were talking about our strategy for GDPR compliance, but I'm sure a lot of our listeners either are in the midst of it or maybe they're a little bit behind trying to get ready and get in front of GDPR compliance. So, as a starting point, could you just explain what this is and why should we care? Sure. I mean, GDPR stands for the General Data Protection Regulation.

It was actually enacted last year. It becomes enforceable May 25th, 2018. It really replaces what they call the EU 9546 EC Directive. And the big difference between GDPR and the directive is GDPR is an actual regulation, where the directive was kind of more guidance and recommendations. And from that, a lot of the countries around Europe adopted their own privacy rules and regulations, which always creates problems for people.

Opportunities for others.

There is, you know, everybody talks about the potential fine base, you know, and all attributes associated with that. Fines are only going to come if you're purely negligent in nature. The fines are significant in nature, up to 2 to 4% of your annual turnover. So it's annual revenue, like worldwide revenue, right? Annual worldwide revenue.

So I think that's worth pausing there for just a second. You know, if you're a billion-dollar company, you're talking about what, a $40 million fine? Fine, if you hit the 4%. Yeah, so I mean, that's a lot of money, and that's revenue, right? Not profit.

That's right.

Yeah, so I mean, it's really structured around to address the current state of technology, international data transfers, and focus on the individual rights, and the rights being around choice, access, right to rectification. Right to be forgotten, or i.e., deleted, which, you know, really applies in a lot of businesses because a lot of businesses are still behind on the attribute of setting up retention and retention periods and following that and following through on that from that perspective. And that's when I, you know, people talk to me about backups and things on that line, you know, it doesn't matter if it's spinning disk, it doesn't matter if it's backups, synthetic or nature or however you want to address the backups from that perspective, it addresses all the data across the board from that perspective. So I know you gave— you handed me and Steven a couple pieces of paper here that have, you know, your summary of this. Is this something that we could share along with the show?

So we'll have in the show— I got a nodding yes. Yes. So I will— I'll go ahead and put a link to these in the show notes as well, kind of the talking points for this, and really what the basics are. You just kind of went through those first basics to summarize it. One more basic around it, and it's really only if you collect data, personal information, personal data out of individuals who are residents and/or citizens of the EU.

That's really the scope around it from that perspective. So if your business doesn't collect personal information, then you don't have to worry about GDPR. But if you do, you Yeah, so I think you make a really good point there, and the keyword there is resident, because one of the things with GDPR is it's not just covering the citizens, it's also covering residents. So if you're a US citizen that happens to be living in Europe, you will be covered under GDPR. Correct.

So what if I operate a mortgage company in Denver, Colorado, and I only do mortgages in Colorado, and someone applies for a mortgage, but they currently live in France. Am I in scope for this? You're in scope because it is European data and data out of a European citizen. So it's going to be awfully hard for any company, from the way I just heard this, to say, hey, that doesn't apply to me at all. Correct.

Yeah. It's an awfully broad brush. Yeah. The chances are of them coming after a one-off are very slim. Slim.

They know they're going after the bigger, the bigger players, but, you know, revenue is revenue for governments, and they always try to find a way to get them. Well, and if you don't have a breach or you don't have a problem, they probably won't know, but then when you do, they'll know. Now you were negligent, right? Yeah. Okay.

Well, the other, the other time that they would probably care too is if they get a lot of reports from their citizens. So for example, if you are, you're, if you're constantly breaking the the rules and a citizen is asking for their data and you're not giving it to them and you're not being cooperative, they probably will come and investigate you at that point. So, it's not necessarily a security breach or anything malicious, but if you're not active or if you're ignoring things, they'll probably also investigate. So, yeah, Jim, you mentioned briefly in your basics the right to be forgotten, and I think Steve might be referring to that right there. Basically, an EU resident can tell anyone who has their data, get me out of your systems, I want you to— I want to be erased.

Is that kind of a nice summary of that? It's an actual summary, but the other component around that is businesses have the obligation sometimes to maintain data for compliance purposes, whether it's legal, you're in a litigation process, you're doing compliance. So back to that mortgage example, right? I can't forget you. I issued you a mortgage, right?

So they, you know, that's one of the things that business has to clearly specify to the individual in their transparency and their notice is sometimes they can't delete all this information. They can remove it from their marketing systems, sales systems, contact systems. But if they have a legal obligation or regulatory obligation, they need to maintain it and keep it. Yeah. Okay.

So we got the basics. Do you want to dive into the, you know, kind of section 2 here, the GDPR areas? Yeah, and I kind of broke those areas into the way that the overall regulation is structured. It's 163-some-odd pages, and we've got about 10 bullets on a half a page. So it's really summarizing, take it at a high level.

But the first piece is really awareness. You know, is your organization aware of it? Do they know what they do and cannot do from that perspective? And it expands outside of the organization to your third-party service providers, whether they're, you know, cloud computing, etc., things along that lines, that you have an obligation and pass that liability because there is that huge liability, potential liability there to your third parties, and you have to make sure that they're compliant from that perspective. And then finally, your executive committee, and I'll talk a little bit more about what your— the expectations are on the executive level on that side.

So when you talk about awareness, what is, what is it you're trying to make people aware of here? One, the individual rights. So me as an individual, a citizen, a resident of the EU, that I have a right to access. So if somebody calls my call center and says, hey, you know what, I want to have access to the information that you have on me, you have to provide that vehicle or instrument for them to do that. And it's typically in the same fashion or format that you collected the information.

So if you collected it from a website, or if you collected it on physical documents in retail, etc., some things along that line, you have an obligation to provide that access in the same means that they— that you collected it. So your point here on awareness is basically that you don't want the first time that they hear of it to be from a resident of Europe asking for the data. Is that basically what you're getting to here? I mean, you call a call center and they get, what? I don't know what this means.

What's a GDPR? Is it a new vehicle?

The next area is really data inventory, and this is where a lot of organizations will struggle because they really have to map out and understand where their data is, what systems it resides in, databases, applications they may have, whether it's, you know, on a website, on a mobile application, etc., things on that lines, they really have to understand where's my information and then who has access to it. And of course, finally, we'll talk a little bit more about the retention aspects associated with that. Steven, when you and I have talked about that, you mentioned kind of the data flow responsibilities here. Would you kind of lump that in the same area? Yeah, so obviously data inventory is important, and here at Ping we've started a program where we're actually now tracking all the data.

But after I've been going through some of the GDPR, some of that, those 163-some pages, one of the things that is becoming more evident is they're actually more concerned about data flow, of how the data flows around your organization, not necessarily the individual systems, but when one system transitions to another system, which transitions to another, and making sure that you've got an understanding of where that data is going and how it's being controlled. That's really the next step that we're taking here at Ping is to really understand the data flow across our organization. Which is monumental for a lot of organizations. It really goes a level beyond what data is sitting in a database somewhere to where are all the exposure points for that data. Everywhere, right?

I always say that a lot of organizations collect this data in a structured environment, right? And I consider it like a glass of water. It comes in, it's refined, it's contained, and then what do most organizations do? They take that glass of water, pour it on the table, and it flows everywhere. It's just amazing.

You'll find it in Excel files, you'll find it in Word files, you'll find it on SharePoint sites, and you sit there and you go, like, you know, for the PCI DSS, right? Well, as your QSA, you're not going to sit there and say, you know, all my data is over my email system or my Access database or this and this and this. And now you got me thinking about the water that we don't realize it's rotting away somewhere in a corner, mildewing, and it's going to cause us problems in a few years, right? It's a good analogy. I'm gonna remember that.

The next area is really around privacy notice. So this starts at the point of collection. So when the individual Whereas a client, a customer, and that's a big differential for Europe and US, is it's not just customer-driven, it's also client-driven. So it's business information, not just individual information. So a lot of times you'll collect business information about, you know, Joe, where he works, his contact information, etc.

So it extends beyond just the traditional customer to the client as well in a B2B environment. But your notice has to be clear and transparent and simplistic in nature. I know I've written hundreds of privacy policies and privacy notices and statements, and of course in the US under GLBA you have an obligation to follow this format. Most individuals won't read it, they don't understand it, and they really want to simplify it. So they say, all right, I'm collecting it for this purpose, it's for buying this product, for providing this service.

And once that— once you complete that obligation, you also have to provide notice that, all right, I may resell this information, I may use it for marketing or sales purposes, I may use it for profiling you. So you really have to be clear and transparent on your notice from that perspective. And that's where probably most regulators will ping you on, is they'll look at your notice and they'll come in and audit your practices and say, you're saying X and you're doing Y. And that just tickled for me that there was a There was a recent fine against a— I'm about to say this— against a sex toy manufacturer who did not say what they were collecting data for, and they sold that data, and then they got some significant fine. Have you— are you familiar with this story?

I'm familiar with the story. Yeah, it was a recent one, right? Yeah, it was Wi-Fi enabled. As I started the sentence, I didn't remember that it was a sex toy. That's where we are.

Yeah, so one thing I would like to add to the privacy notice is, you know, obviously privacy notice is an important thing with GDPR, but here we're also looking one step further because GDPR not only just covers customers, it also covers your employees. And so if you have any employees that are overseas or in Europe, you also have to have a privacy notice to describing what you do with their employee data and make sure that you have that covered too. And that dovetails nicely with the Privacy Shield that just came out from the United States. Yeah, a couple comments on that. One is it's hard to get what they call consent because you give notice to the employee, but how do you get consent that's free from obligation?

You're collecting that data at the paying. You're collecting that data to evaluate their performance. And under GDPR, it has to be separate. Your notice and consent has to be totally separated from that perspective.

It's interesting. So what is the approach then for getting consent from an employee if you're not supposed to tie it to compensation? It's really just a single— it can't be within within the employment contract, because in Europe a lot of times they use the employment contract. It has to be a separate document within the employment contract, and actually the employee has a right to refuse. And can their employment be contingent upon acceptance?

No.

So if you refuse, then we can't monitor your ability to do your job? You have to go through a manual process to pay and compensate and evaluate. That's what you would call call it sticky wicket. This is a sticky wicket, isn't it, guys? It is.

I dealt with that on a number of mergers and acquisitions in the past years because certain countries within Europe had similar obligations.

I think, still in the same area here, Steven, when we were talking about it, you mentioned it's employee data, customer data, but then there was also the monitoring data? Yeah, so So under GDPR, one of the new things that they introduce, and this is something that's been around but hasn't really been addressed by the legislation that we have right now or regulations, and that is the concept of big data and the monitoring. And, you know, a lot of companies are now mining that data to try to find insights into patterns and buying patterns, etc. And what the GDPR has done is they put some rules or around what you can do with big data. And so, if you have any type of strategy that involves that, GDPR is definitely going to be a factor in what you do with that data.

So, this same data, would that be part of the privacy statement then? Yeah. You should incorporate that as well into your notice, especially if you really plan to, because a lot of times you'll collect data and resell to data brokers. Or a data broker, or a pool from a number of sources. And if you're a data broker, you— the first thing you got to do is ask the client that you're getting the information from, what was your notice, what was your consent, to validate that they can actually use that data for the processing and purposes they have.

So does the data broker— is the data broker on the hook, or is the person who sold the data on the hook? It could be both. Okay, both of them. That's probably the right way to do it if you're trying to actually accomplish something Right? All right, I know I'm making this go slow, so I'll let you guys talk a little bit.

Next area is individual rights. We kind of touched upon that on the basics. The right to be forgotten, deletion. Of course, you have that carve-out for requirements for legal or compliance obligations. The right to access.

Customer has the right to access their information, which I talked again, in the same means that you collected it. And then consent. You know, the consent has to be free. Willing, without any obligations tied to the collection of that information. Now, you can use it under contractual terms, i.e., you're signing up, you're buying a service, and it's defined in your contract, but it can't be within the contract.

It has to be a separate document, or basically click on a website to say, yes, I acknowledge and accept. Right. And that's a big— that's a good point, is when it comes to consent. It can't be implicit. Here in the United States, we tend to like to use the opt-out feature, so we assume that you want to participate.

In GDPR, and also in some other regulations around the globe, they actually require you to have a fully consent box, like a box that says you must check it, and it can't even be checked already. It must be clicked on by the individual, so you can't lead them, you can't do anything like that. All you can do is ask them the question and then they have to literally click the box. Can I make the yes box bigger than the no box? That hasn't been tested yet.

There is what they call opt-in versus opt-out process. Yeah. Okay. Data breach. Of course, in the US, we're very familiar.

We have now 49 states and territories that have data breach obligations. Sure. Where you have a certain period of time to investigate. In GDPR, it's 72 hours. Now the question is, you know, pulling the trigger.

Do I have to notify a regulatory authority or data protection authority, DPA, in Europe within that 72 hours to say, you know what, my CISO called me and said, hey, we think we've had a breach. And of course, thinking and knowing are 2 different things. So that's going to be one that's going to kind of be tested to see whether or not, you know, if it's first point of awareness or actually finding out that there's potential harm and misuse of this information. Anyone who's ever been a part of an incident knows it really is a spectrum, right? From, from the idea that, hey, there's something weird going on to, okay, I've now confirmed that there's a bad thing.

There's a whole lot of shades of gray in there, and at which shade of gray am I supposed to notify? It's always a hard call. And one of the things that we run into here a lot is we actually have a lot of contracts with a lot of customers that try to supersede notification outside of the relationship we have with the customer until we notify them. And so, that's one of the things that we have to balance here is, you know, do we notify the regulators per GDPR, or do we need to notify the customer, or do you just have to act really fast so you can notify the customer and then the regulator before the deadlines all— And you're a server— in that case, you're a service provider to the customer. Correct.

And the customer has the obligation to make the notification. Good point. You need to assign what they call a Data Protection Officer or DPO. That role they define clearly in Working Party 29, which is a working group that kind of works around these data privacy rules in Europe. Clearly specified, you know, it can be an internal individual, but they have to have separation of duties from that perspective.

They can't be— their day-to-day role can't be tied to business deliverables. They have to operate independent and freely and be able to make a decision to say, you know what, I've got an obligation to make a notification to the data protection authority, and your CEO can't say no, you can't do that. So that DPO really has— is on the hook for that responsibility around that. So I want to dig into that a little bit. You have on your notes reports to executive officer.

Who in a company do you think, choosing— assuming you choose to do an internal person, what roles would you see filling this generally inside a company? Well, there's been a lot of bantering about this out there. The people in the legal profession want to protect themselves and say it should be a lawyer. And then there's the opposite side of the coin, which is probably 50/50 right now, to say somebody who has the capability to understand technology. To understand your operational practices, your disciplines, and how you're processing that data and using it across the system, across the environment.

So it's a 50/50 really from that perspective, but somebody who really understands what the obligations on GDPR are and understands technology, and not the bits and bytes level, but, you know, general speaking technology from that perspective, and then being able to overlay that to the operational practices and disciplines that you have. So what I heard you say, lead lawyers, so maybe the general counsel might be one. You really don't want to put your general counsel in that position. Okay. Because you really want to keep that one arm's length away from making a legal decision to a regulatory decision.

So if you make a legal decision, it really becomes, all right, I put my company at high risk because because I said no, and a regulator comes in and finds fault. So now you've got 2 problems. You've got the liability associated with GDPR, and do you have a legal obligation where you might have class action against you because of that decision? So it's not the general counsel. So who is it?

Anybody, you know, anybody who can fill that role, as I talked beforehand, has it. But who does that in a company? Give me a title. Well, in the previous case, when I was a CPO, the Chief Privacy Officer, Western Union, I was— I could be one. The privacy officer might do it.

Would you see a security officer doing it? Security officer can do it. Security, privacy, maybe a compliance officer. Okay, so one of those types of roles. But they have to report at a high level in the organization.

You can't bury them down within the organizations. So really, they're really pushing for that individual to report to somebody in the executive committee or even the CEO. Okay, fair enough.

The next area was legal basis. So you really need to document why you're collecting the data, how you're processing it, the purposes of processing it. You're going to need to understand your fulfillment purposes. You know, am I fulfilling a product to the individual who's, you know, buying my product or service that I'm providing to a client or an individual, or am I also using it for secondary purposes? What I call secondary purposes: marketing, sales, profiling, you know, big data environment from that side.

You need to have that clearly documented and be able to produce that documentation and the evidence around what you're doing to the regulators. So when you talk about the legal basis, are you actually talking now about Like, if we embed this terminology within our contracts, is that sufficient, or do we actually have to have some policy or some guidance first, and then we point to our contracts that reflect that guidance? It should be in your third-party contracts or your even intercompany contracts, because a lot of times you have— you're working with multinationals, you have various entities that report in Europe, but they report back to a US entity. And that is— I'll talk maybe a little bit more deeper on the international transfers, but you have intercompany agreements. Yep.

And you can use tools such as what we call BCRs, binding corporate rules, or model contracts. These are all instruments that enable the international data transfer but also put the liability and responsibility on your internal entities or the third party. Okay.

The next area is data protection impact assessments. In the US, they call them PIAs, privacy impact assessments. It's really understanding your systems, your applications, and how are you using that data, and does that line up to the requirements in the regulation? And it needs to be documented. Again, evidence be able to be provided if a DPA, Data Protection Authority, comes in and says, hey, I want this documentation, and you got to say, all right, here's the boxes I checked.

I checked data, you know, this sensitive data, you know, whether it's medical, financial, etc., it's sitting, it's transferred, it's encrypted, access is controlled, etc. All those components under the data privacy assessment really needs to be documented. And we all know it's a point in time, so can you do it once? No, you should do it on a periodic basis. Right, and I assume it's a pretty similar process to a risk assessment, you're just looking for different risks, right?

And you're documenting that you have put these, these requirements into practice. Mm-hmm, yeah, fair enough. Data security, you know, periodic evaluations would be third-party service providers making sure you have contractual terms in your contracts with the third parties, because if they come knocking on your door and your third party's providing a service on your behalf and you haven't done any diligence on it, you're gonna get nabbed. Sure. Of course, encryption, logging, everything else that usually comes along with the typical security environment should be part of that program overall.

Now, this is something that comes up quite a bit. When we work with our customers, and that is the contractual terms. And so we do a lot of business with a lot of large SaaS providers, etc., and most of the time they give us their contract and we don't have much say in what it does or how they do it. And so what we rely on a lot is their SOC reports and their ISO reports, etc., and they make a commitment in their report in their contract that they will maintain these reports, etc. And I guess the question that we have here is, you know, is that sufficient?

That if they say that these are the controls and they say that we will continue these reports showing that we have these controls, is that sufficient? Or are they actually looking for the controls to be spelled out within the contractual terms and, you know, that we can tick and tie and say, you know, you do this, or do you not do this? I mean, they just give us these reports and we rely on those because they're done by third parties. And you can leverage those reports as part of your agreement between the two parties.

But I'm sure at some point along the time, somebody's going to come back and say, you know what, did you do any further diligence besides looking at their documentation? Yeah, but if the documentation was attested to by a third party, an ISO certification or a SOC 2 or whatever, isn't that the due diligence? It is due diligence, but I'm sure somewhere along the lines they're going to push on that. Is this something that we should be worried about today, tomorrow? I don't think so.

I think it's a good practice to have in place and leverage that information. But somewhere along the lines they might come back and say, you know what, did you even check that third party? Did you, you know, was this third party actually in a garage and actually had the proper— How do you, how do you know, right? How do you get assurance that that is a real report or whatever it is, right? I think having thought through those questions makes a lot of sense.

The next area is data classification and retention. They really want you to identify the data you have, classify it, and classify, you know, it could be general information, it could be secret, it could be top secret, those type of examples. And really, that applies and drives, of course, your information security requirements behind it. If it's just public information, then, you know, your security requirements diminish. But if it's all credit card data or all health data, then you should have stringent security practices put in it.

This one, this one really just ties to any, any typical security security standard, right? If you've built a good, a strong security program that adheres to any of the standards out there, you should be doing this already. And then you should be able to measure it, you should be able to provide metrics to it. They're going to want, again, that evidence to say it's happening. And then finally, retention, which everybody avoids.

Everybody and their brother retains data, and it's humanistic in nature. I want to keep this data as long as I possibly can because I might need it 10 years down the road. And if you— in your definition of retention, of course, especially on an international basis, you have different obligations. You know, under BSA in the US, you know, 5 years to retain your data for those purposes, etc. Employment, I think it's 50 years in Lithuania to keep your employee data.

So To specify your retention schedule really takes a lot of diligence and work understanding your practices and the country obligations around that from that perspective. But once you're outside of that, if your retention period says keep for 5 years, you have a breach and you got 7-year-old data, 10 to 1 you're going to get hit for that. So what— is there a magic number? So one of the things that we struggle with is exactly what you're talking about, where we have a variety of different customers that want us to have retention periods. We have a 2-year retention period just because that's where we drew the line.

But, you know, we have customers asking for 7 years, we have customers asking for 6 years, we have customers asking for even shorter than 2 years because they don't want it out there. So what, what is the— this— is there a safe play when it comes to data retention? Or, I mean, how, like, if you have a system You know, how do you control that one country has it for 2 years, another country has it for 5, etc.? Like, how is that managed? There's no crystal ball here.

There's no easy answer. It's, unfortunately, you have to apply based upon jurisdictional or country requirements and upon that discipline. So again, if you're doing money laundering or anti-money laundering from that perspective, you have certain obligations in that If you're keeping it for employment purposes, you have certain obligations, and they do broadly vary from that perspective. And I have an example retention schedule up on my website that people could pull down and look at, and it talks about the various areas, whether it's internal governance, whether it's employment, whether it's finance, tax, logging, you name it from that perspective. There's an example there, but it shows you the complexity.

And my key point to, you know, organizations who do this, do not define a retention schedule down to the nits and grits, because that just opens up opportunity and liability for you. So take a general practice to say, you know, I need to incorporate employee data, you know, for the majority of the cases it's 5 years. Some cases exceptions are, you know, country A, B, and C. Should you list out those exceptions, or should you say— Yes, you should. Okay, so that's getting pretty nitty-gritty then, isn't it? But it's not getting down to the actual data elements.

Okay, just buckets of data. Okay, I got it. All right, last point here on your areas, right? International data transfers. I talked a little bit before about that.

One is part of GDPR. You have to identify who your lead authority is. So your data protection authority could be in the UK, could be in Ireland, could be in France, could be in Germany, and that's who you are responsible for reporting to, making notifications to, from your organization. And the second thing they're going to look at is, all right, is, you know, what are the vehicles to have you done? Binding corporate rules, BCRs, is a very extensive process.

You go to your lead regulator and you really have to document all the collection, the purposes, the systems, the practices, your policies, your standard operating procedures, your standards controls, and it's part of that application of the BCRs. Model contracts are a little bit different and are contracts, again, typically between either third parties or internal parties. The one thing about model contracts you can't modify them. You have to take them as they are, otherwise they become void. So they're clearly defined and articulated, and if you try to modify them, then they'll say they're void, and therefore you have been transferring data out of the EU invalidly.

And then finally, Privacy Shield. You talked a little bit about Privacy Shield. That's gone back and forth. It was Safe Harbor beforehand. And now the EU is actually coming back and some of the authorities out of Brussels are coming back and questioning that.

So I do think, you know, there's probably some confusion out there. What's the difference between Privacy Shield and GDPR? Could you give a high level, you know, where's one stop, where's the other stop? Well, Privacy Shield is what I'll call an instrument, an instrument that you complete to say, all right, this is how I'm going to transfer data between between my entities, whether it's in the US, to third-party entities and others. In a way, Privacy Shield was structured as well as Safe Harbor was, it was really meant for data to be transferred out of the EU to the US.

Onward transfer really wasn't covered under Safe Harbor or Privacy Shield. So, if you pull data into the US and then onward transfer to somewhere else, you are actually out of compliance with the you're filing. So it's an instrument that enables you to do the international data transfers in a component within GDPR. I don't know if that makes sense. Sure.

So that's— you kind of got to your areas of GDPR. Stephen, anything that he didn't cover there that you wanted to pull out as interesting from GDPR areas? No, I think that pretty much covers all the main points. The only thing I would add is, so while Privacy Shield, especially in our political environment right now, is being questioned by the European authorities, there's really no safe harbor, you know, not to use the safe harbor term, but there's really no place right now to go to make sure that you have 100% assurance that something's not going to be overturned. 'Cause even the model contracts are even under question within the EU.

And I think Ireland is taking a look at that right now. So even if you have model contracts, you have to monitor the situation because those are being questioned. Privacy Shield is still being questioned across the entire EU. And BCR is incredibly complex. So really, you just have to keep monitoring and just keep pivoting whenever you have to.

The important thing is, you know, having your program documented and being able to produce evidence that you're following your program and the requirements of your program. So there was some recent news in the US where Congress has passed a law to allow telecom— telcos to collect and share privacy info, right? So My ISP can now, you know, collect information about my finances and my browsing history and all this, and they can go sell that, and that's now legal. Well, it was legal beforehand. But wasn't there a regulation that— The prior commissioner for the FCC enacted and put into— it was actually supposed to become an enforcement this year that you were supposed to provide notice consent about what you're doing, how you're collecting that information, etc.

And that was just recently overturned. So they're not actually changing any practices, they were just— it was going to become illegal and now it's not going to be. Do you think there's any impact to Privacy Shield or international business based on that recent change of policy? For the FCC change? I don't believe so.

No direct correlation. No direct correlation. You know, it's just good standard and discipline to, you know, if you're gonna be using Jim Keese' data, let him know how you're using it. You're giving me the right to make a selection of how I want to use it. So I know we're gonna get a little bit into, into key areas for InfoSec professionals, but, you know, I'd say let's, let's assume that there are people listening right now who just heard a lot of stuff that they have to worry about and they're not sure what to do next.

What should we do next to go get ready for GDPR that we have, you know, about what, 14 months, almost 15 months before it becomes the law of the land? One, I think especially you need to get a DPO. You need to assign a DPO, whether they're internal or external. You can, you can outsource it. Does it, does the location of the DPO matter?

Should I have a DPO that's local to my headquarters? Should I have a DPO that's in the offices in the EU? What do you recommend? Your data protection authorities are going to be looking for somebody that they can reach out to locally. Now, is that practical in nature?

No, because the International Association of Privacy Professionals, or IAPP, has provided an estimate there's going to be a need of at least 28,000 people to fill this role. And some put it as high as 75,000 people to fill this role. So, is it practical in nature to have them all in Europe? No. But you have to have the individual you assign the responsibility for, has to be reachable by that authority in an easy fashion.

So, you know, it can't be, I want to get a hold of Jim, he's in in the US and I'll get to it, he'll get back to me in a week. Usually it's typically response within 24 hours or a complaint, something along that lines. They can interface with you directly. It's going to be really critical in nature. And then building that relationship with your lead authority, it's going to be critical in nature.

Saying, all right, you know what, I know Billy Hawkins from Ireland who's the Data Protection Commissioner. Sure. Hey, Billy, can pick up the phone and talk to me. So probably the privacy consulting consultancies in the EU are gonna be doing really well here in the next, in the next few years, huh? Yeah, yeah, there's a high demand right now.

All right, so one thing we need to do, we need to get a DPO named. What else do we need to do? One is you need to document what's your approach to GDPR. Figure it out, go figure it out. How am I going to address this?

And I really start with your data inventories, your data mappings, and getting that discipline in place. The next area I would really focus on is what's your notice and consent? Because you may be operating websites in 10 different countries, and the first thing a regulator is going to do, which is very easy for them to do, is go look at the websites in those 10 countries. And if you're saying your notice on Site A, you're doing XYZ, and Site B, you're doing ABC, they're going to hit you. So really streamline, get those consistent, and making sure that the language is consistent across all your infrastructure in that nature.

The other area is really what is your internal process as far as creating awareness and training and getting that critical buy-in at the executive level. Those would be the first 3 steps I see that you really need to address going into it. And at least that way, you know, just like any regulator, if you can provide evidence that you're working towards it, even though you had a complaint or some type of action against you, they're usually going to give you some time and discipline to correct those. Sure. So, Stephen, any guidance you have for people for next steps?

Anything that Jim didn't mention you want to point out? I think the only thing that I'd really point out based on what I've been working on is, and I was just talking to Robb about this, is, you know, it is May of 2018 is the deadline, but when you start actually putting it down on paper as far as trying to hit milestones, you start to realize that you don't have really that much time. I mean, we're already coming up to I think it's about 450-some days until it goes into effect, and all of these steps do require some planning and some time to get them put into place. So that'd be my number one thing is make sure that it's on your roadmap, make sure that you are taking your steps to put these into effect, and just be prepared because when it comes through, there is going to be an initial flurry of compliance and that type of stuff. Stuff.

It should settle down, but you want to make sure you're on the front edge and protected. So don't think you're gonna go jump on this in the middle of April of next year, is what I hear you saying. Exactly. Start working backwards and figure out a good implementation plan. Yeah.

Find your resources because they're really gonna be hard to find. Yeah. And get your funding. Get in front of your executive committee, your finance committees, and say, right, what funding do I need to do this? Yeah.

Because Because like you say, if you get around to budget planning in July, August for the next year and you don't have it there, it's going to make it a lot harder. And it really makes you look bad, right? Hey, you come in, you know, next— you come in in December, January and say, hey, I'm going to need an extra million bucks next year and it wasn't in the budget. All it does is make you look bad like you weren't planning ahead. So it's good to get on top of it.

I think this has been really good. Hopefully educational for folks. Any— I'll give you guys a chance to give your contact info. Any other tips about GDPR before we move on to the next phase here? Well, I think we talked just, just about them right now.

Don't wait. Don't wait. Yeah, I mean, we're seeing it. There's a lot of, you know, chatter in the industry about it, but we're not seeing a lot of clients, customers moving forward on it. So if I call today, I can be the first in line?

Okay.

So in terms of reaching out to you guys, you know, you're both here, Denver local guys. If folks have questions, are you— I know, Jim, I know this is what you do professionally, right? So folks can reach out to you for consulting. And so how would they get a hold of you? Yeah, it's— you can reach out to me at jmkees@privacy-internationallp.com.

I'll put that in the show notes as well. And you have a website as well? Website, there's a Contact Us page up on the website. You can fill out the information. I'll have that in the show notes as well.

Steven, do you mind if people reach out to you if they have questions or anything? No, they feel free to reach out to me here at Ping Identity. My email is sedmonds@pingidentity.com, and Robb can put that on the webpage also. And I'd be more than than happy to talk with anybody who's looking at doing GDPR. Only the first few.

If too many of you call him, I'm gonna cut you off because he has a job to do too. Well, that's great. This has been really useful. Hopefully those who didn't know about GDPR are now starting to get a little nervous and get a little momentum moving forward on that. Appreciate both of your guys' time, and we'll look forward to Talk to you soon.

Awesome, thank you.

Learn more about the Colorado security scene at colorado-security.com, where you can see information about local security groups, a calendar of upcoming security events, and learn more about Colorado Equals Security. Reach out to Alex and Robb by emailing info@colorado-security.com.

Until next time, Remember, Colorado equals security.