IT ALL BEGINS WITH POLICY

Kip Boyle: 

Hi. This is Your Cyber Path. We’re the podcast that helps you get your dream cybersecurity job. I’m Kip Boyle, I’m here with Wes Shriner. We are experienced hiring managers of cybersecurity professionals. Welcome to this episode. Hey, you can listen to the episode as an audio only recording in your favorite podcast app. You can also watch us if you actually want to see what we look like, you can do that too. Just go to our YouTube channel, get up to YouTube and search for Your Cyber Path podcast, it will take you right where we are. 

So this episode is the next one in a series. We’re doing this huge series that’s designed to tell you all about the way that cybersecurity organizations are put together, what services they perform, and the idea for you is you want to do some career planning, you want to get your dream cybersecurity job. Well you should probably know what your options are and as you grow your career, you’re going to want to know what those options are as well. So today, we’re going to drill into one particular service, it’s the security policy service, and when we show you the placemat, kind of the where are you diagram, that’s going to be number 21 in the service catalog, so we’re going to do number 21. And as we do, we’re going to explore it with a guest. So Wes, will you please introduce our guest Torin.

Wes Shriner:

Kip, it’s good to be here today. We’re going to have a lot of fun. I do look forward to taking on the policies and standards of a security organization in a fun and exciting way because that is sometimes considered a dry subject. So we’re going to liven it up. It’s going to be a good time. We’re going to have a good conversation and I think it’s going to be fun doing it. 

I’d like to jump ahead here and introduce Torin Larsen. Torin and I have worked together off and on over the last eight, 10 years, something like that. He’s the managing director at Protiviti. He delivers security and privacy solutions to businesses all over the Puget Sound and the country. You can find him on LinkedIn or you can find him kayaking with his kid near Bainbridge Island. So it’s a pleasure for me to introduce the guy who has done 100 policy projects around the area and probably at least one or two for me. So Torin, tell us about yourself.

Kip Boyle: 

And you can still talk about it. Hey Torin.

Torin Larsen: 

Hey. Thanks for having me. Yeah, so happy to be here. Appreciate the opportunity to talk to you guys and be part of the show. So just a little background on me, as Wes said I’m the managing director at Protiviti. I got my start in security at Protiviti. I had done a variety of different IT jobs before coming here and I started out doing web development when web pages were less sophisticated than Microsoft Word documents are today, and I’m looking at Kip because I think he probably remembers those times, right? 

Kip Boyle: 

That’s a very accusatory statement, sir.

Torin Larsen: 

No, no. I’ve been listening to the podcast. I’ve heard some of your war stories, so-

Kip Boyle: 

Oh yeah. Yeah, yeah, yeah. Yeah, like the first time I got on the internet, there were 10 web servers. Yeah, yeah, yeah.

Torin Larsen:

Yes, yes, exactly, exactly. So yeah, doing very specific web dev, it got more sophisticated from there. I’ve done server administration, network administration, cut my teeth in a Novell network and NetWare environment back in the day and kind of worked my way through IT to the point that I was running a desktop support function. And then a friend of mine talked me into coming to Protiviti. Protiviti was relatively new at the time. It was only about four years old, we were founded in 2002, and I started doing basic consulting level stuff. We were very much oriented towards Sarbanes-Oxley in the day because that was the new regulation that had just come out. We had been formed out of Arthur Andersen, which was one of the big five consulting firms back in those days, and we were acquired by Robert Half International which was the biggest … Sorry, the largest and oldest staffing firm I think in the world and we started as 700 people. I think I was around maybe person number 1,200 or something like that, we’re about 7,000 today, we’re in 20 some different countries and fairly big at this point.

But I started at Protiviti again through an introduction through a friend. My first project was an SAP project and I was thinking, “I already know all this IT stuff. Do I want to start from ground zero on SAP and learn something from the ground up?” Like, “At this point that just sounds pretty boring.” So I looked at what the options were, I had always had an interest in security from doing IT work and luckily Protiviti has a great mentoring program and I reached out to my mentor and I said, “Hey, I heard about this big project up in Seattle,” at the time I was in L.A., “I’d love to go do that security project,” and low and behold, two projects later-

Wes Shriner:

You just wanted out of L.A. You just wanted out of L.A.

Torin Larsen:

That actually is who I am. I am a Pacific Northwesterner. I had been down there for school and started my career down there and actually it was being at Protiviti in L.A., I don’t know if I should say this or not, but doing consulting all over the Greater L.A. Basin and starting to have to drive on freeways and stuff was a very different life from just working in IT where you’re a mile from home.

Kip Boyle: 

So you wanted the next bus out of L.A., and you got on the cybersecurity bus.

Torin Larsen:

I did actually, and I was lucky enough to get on a project in San Diego and that kind of pivoted me to like, “Oh, I can just be a remote guy and then I can live in Seattle,” and so I managed to get back here kind of quickly which was amazing.

Kip Boyle: 

So I want to point out two things to the audience here about Torin’s background, right? First of all, how did he get to Protiviti? He had a friend. That’s how you get the best jobs is you know people and they tap you on the shoulder and say, “What do you think?” Or you call them and you say, “Hey, I’m ready for a new opportunity. Do you know any?” So that’s one thing I want to point out. The second thing I want to point out is the pivot-

Wes Shriner: 

I’m going to cut you off and come back to that, Kip-

Kip Boyle:

Okay.

Wes Shriner:

I want to hear your number two, but it’s because you’re doing your best work where you’re at that someone taps you on your shoulder. You don’t get there by being irritated, disgruntled, and, “Why am I stuck in the mail room?” No. You’re doing what you’re doing and you’re doing it to the best of your ability and that’s how you get tapped on the shoulder for the next thing. Back to you, sir.

Kip Boyle: 

No, that’s true. That’s absolutely true. That’s a great caveat, and then the pivot, right Torin? You pivoted, right? You looked for an opportunity to take a step towards cybersecurity and you did it and so I just want to highlight that those are golden things that you should be trying to do. Okay. Thanks.

Torin Larsen:

Yeah, no, and so that was 14, 15 years ago. That was my early days in Protiviti and I’ve been basically doing cybersecurity ever since. There’s been a smattering of other things but it’s been the majority of what I’ve been doing. My clients, I tend to work with the technology industry, and I was joking with Kip earlier. We tend to have clients that are either gigantic clients that are like 50 hundred billion dollar plus or we have small startup clients that have nothing in place and need help with everything, and it’s funny because we don’t have a lot in between, but that’s exciting for me and that’s where I spend all my time and loving it still, and consulting is great because it’s something different every day. Different clients, if you have a bad project, there’s always the next project and it’s never too far away, so …

Wes Shriner:

Very cool. Glad to have you here, Torin. I have enjoyed working with you in the past. I wish you a long and successful career in the Great Northwest, where we get to do this again.

Torin Larsen: 

Yeah, well thanks for inviting me.

Wes Shriner:

We’re going to jump to get into our topic in just a second. But before we do that, I need to give you the farm story.

Kip Boyle: 

Oh yes. Yeah, let’s hear what’s going on the farm, man.

Wes Shriner: 

Life on the farm-

Kip Boyle: 

It’s spring. It’s almost spring, right?

Wes Shriner: 

Almost spring. The forsythia have not bloomed, the camellia have not bloomed. It is not quite spring yet on the farm but we’ll get there. What is happening though is it’s the start of peacock mating season. 

Kip Boyle: 

We’ve heard about the peacocks before.

Wes Shriner:

I know you’re on the edge of your seats, worried about this. The peacocks lost all of their feathers in August-September, and now it’s February-March timeframe and those peacocks are growing their feathers back. The males grow the large fan and the females do not because the males are out there attracting mates. Peacocks usually throughout the year just scream when they see a predator that they’re worried about. But during the months of March, April, May and sometimes June, they scream to attract a mate. And when I say scream, I mean the screams of a peacock are legendary. If you haven’t heard it, look it up. It is the sound of help, screamed from a baby. Help. Help.

Kip Boyle: 

Blood-curdling, right?

Wes Shriner: 

And that’s the sound that you hear from a peacock. Help. And that is how they attract their mates. Well my neighbors love that. They do. They love it. They think, “Oh, so sweet. Love is in the air.” All night long, all day long, every day. So we’ve had the peacocks a couple years now and I want to talk about something from the farm that applies to work. We know that a lot of the metaphors that we gather from the farm are actually true, even though we use them at work and don’t remember that there’s a lot of grass to mow, there’s a fox in the henhouse, don’t count your chickens before they hatch.

Kip Boyle: 

Low hanging fruit.

Wes Shriner: 

Those are all truisms from the farm. Well another one is when you have one neighbor who doesn’t like the sound of the peacocks and that neighbor might go door to door talking to other neighbors about not liking the sound of the peacocks, and gathering a neighborhood support for telling you that he doesn’t like the sound of the peacocks-

Kip Boyle: 

Is there a petition? I want to see a petition.

Wes Shriner:

But then that neighbor then brings you the information, but you’re not home. So the neighbor relays it to your wife, who might already be insecure about the sound of the peacocks all the time anyway.

Kip Boyle: 

This is all hypothetical, right?

Wes Shriner:

Hypothetically.

Kip Boyle: 

Totally hypothetical. 

Wes Shriner:

That might be a bad situation for you and the peacocks, and peahens and peachicks. Future peachicks. When we’re at work and we have to deal with conflict, when we have to have a crucial conversation with somebody, we don’t go around and talk to eight other people before we go talk to the individual. The best way to deal with conflict is to make an appointment with them and say, “I’d like to have a hard conversation with you about this topic.” So they can come prepared and you can come prepared. You set a neutral space, you have a … If you need a mediator, you can have a mediator, but oftentimes you can just handle it with some basic ground rules about how we’re going to discuss this tough, hard topic, and then we’re going to move on, and that’s how a crucial conversation can be held. I recommend the book, if you haven’t read Crucial Conversations, it’s a valuable book to have. I also do not recommend going on a podcast, to the internet, and talking about your neighbor. Because that is also not a great way to solve neighbor relationships.

Kip Boyle: 

Yeah, but all this grown-up talk about having crucial conversations, boring. Come on man.

Wes Shriner: 

Yeah, we do love that neighbor. So yeah, let’s move on. We got to jump into security policy which is the light and life of tonight. It’s going to be a good night.

Kip Boyle: 

No man, I just like talking about people behind their back. This seems like the way to go.

Wes Shriner: 

Don’t do this, Kip.

Kip Boyle: 

If I’ve learned anything from reality TV, that’s the way I solve problems.

Torin Larsen: 

Are we clear? I am not the neighbor or the person displayed on the screen. [inaudible], I just thought I’d throw that out there.

Kip Boyle:

All right, I guess we should get on with it then, right?

Wes Shriner:

All right we go, and so a reminder that this is our security placemat. This is the diagram of the 23 common services of a security service catalog. This is the organizational structure of a security org that might include your vice president, your directors, your senior managers in the dark blue, and then your management or individual contributor teams in the light blue. The beige colored numbers are the security services in the service catalog, and today we’re taking on policy. That’s in the governance and the governance risk and compliance space and that is the one service we’ll be talking about tonight. Well let’s jump in and see what we got.

We know that policy is the beginning of all security at an organization but why do we need it? What’s there? The business has made a promise that we’re going to protect the data entrusted to us. Every CEO says you can trust us with your data, but what are the reasons to protect the data? We do it because we want customer goodwill, we want a competitive advantage, we want strong business partnerships, and we want to meet regulatory and compliance requirements that allow us to continue doing business. We’ll get into those compliance requirements another day, so I don’t want to stay there too long today. Stick around, there will be another episode on compliance and that will be just as fun.

All right, types of data we like to protect. It could be anything on the list there. Customer data, employee data, transactional activity, trade secrets, strategic partnerships, pre-released financials. If it’s intellectual property of our organization, it falls in the category of cybersecurity to protect it, which brings me to a question. Are we an information security org? Are we a cybersecurity org? I think we used to be called a data assurance organization. What’s the right name for a security organization? This is where you guys go off and you say interesting things.

Kip Boyle: 

Can other people on the podcast talk about it?

Wes Shriner: 

This is where you guys go off and you say interesting things. 

Kip Boyle: 

Oh, go. That was the prompt. Okay, well you know what? We lost control of everything we used to be called. We’re now cybersecurity. The media has said so, they have declared it to be it, so I resisted it for years and thought it was just this silly thing but now I embrace it and I’m so happy.

Wes Shriner:

When you started was it called systems assurance? The systems assurance team?

Kip Boyle: 

Gosh, it was called data security I think? Or computer security, and then we started lashing the computers together and they’re like, “Well maybe network security.” And then information assurance-

Torin Larsen: 

And at one point it was called IT, right? I mean there wasn’t even, right? Yeah.

Kip Boyle: 

Mm-hmm (affirmative). Yep yep. So, yeah. We’ve had many names over the years and I’ve learned not to get too attached to any of them because I never know what’s coming next.

Torin Larsen:

I agree with that. Yeah, yeah, I would agree with that, and I don’t know what’s coming next either. And I think there’s a lot of discussion these days about does cybersecurity … Five years from now, 10 years from now, is cybersecurity the same function that it is today? Is it something that’s more ingrained in the IT organization, the business? Is the CISO a moniker that we’re going to have five or 10 years from now or is it going to be more holistic from a chief … A risk officer standpoint or a trust officer or something like that.

Kip Boyle: 

Maybe everything’s just going to be block-chained, I don’t know.

Torin Larsen: 

Right, sure, yeah, and that’ll solve all the problems.

Kip Boyle: 

Some people are saying that already, Torin.

Torin Larsen: 

Really?

Wes Shriner: 

Actually I believe every new technology that comes out every other year for the last 20 years has always promised it will solve all of the problems.

Kip Boyle: 

Yes, so dear watchers and listeners in the audience, this is a thing. So get used to it. Everything that comes around the corner is the thing that’s going to save us all. So make sure you allocate the vast portion of your budget to it.

Torin Larsen: 

Yes.

Kip Boyle:

Write your checks now. 

Torin Larsen:

But there’s something to that. I mean you can get a lot more budget for your zero trust initiative than you can for your dinosaur initiative that you were doing 10 years ago that’s really the same kind of stuff. I mean there is-

Kip Boyle: 

And there’s hackers.

Wes Shriner:

Zero trust-

Torin Larsen:

There is [crosstalk] as well.

Wes Shriner:

Torin, what is zero trust? 

Torin Larsen: 

No, don’t get me started.

Wes Shriner: 

Okay. We’ll save that for another day.

Kip Boyle: 

See we have no zero trust here. 

Wes Shriner:

It’s not trusting or inheriting security controls from any other part of the organization. If you own a piece of data you protect it at the data layer level. You no longer trust that you’re inheriting result protections from your system or your network or your environment, your external shell, any of that. 

Torin Larsen:

Yeah, and it incorporates things that we’ve talked about for years. Assume breech, and the internal network is not to be trusted. A lot of organizations have been talking about it for years. But packaging and branding it, zero trust has a lot of new things too. But packaging and branding it does help in some ways if you’re trying to sell your biggest budget. 

Wes Shriner: 

It does. So have you guys been in an organization with real clarity about what they want to protect? Or maybe an organization with not a lot of clarity, a lot of ambiguity about what they should be protecting. And what did that look or feel like? 

Torin Larsen: 

I guess I could say yes, because there are some organizations that have a very straight forward simple environment that you only have one set of data that you care about. Say your employee’s social security numbers, and that’s really all you have to worry about and that’s in some ways a luxury. And if everything else is public, then there’s no reason to worry about it. Few organizations have it that simple. So it’s usually the opposite end of that particular spectrum, and you may not have good data classification. You may not have good understanding what data you have. You often times, you want the business to be the ones making decisions about data. And being the ones that take ownership of that data. But often times they haven’t thought the entire process through and they haven’t thought about what happens if customer sales history goes out. They’re focused on the credit card numbers and that kind of stuff, but they haven’t thought through all the other data that they have. 

Wes Shriner:

I was at one organization as a consultant one time that actually had real clarity. They DLP tool, their data loss prevention tool, was primarily focused on their unreleased coupon book. Literally the whole DLP was around make sure that that coupon book doesn’t go out before it goes out. And they used their DLP for that purpose alone, and that cost us to fight it and it was worth protecting. And it was. 

Kip Boyle:

It’s a digital asset, right? I mean, I think in terms of digital assets. Torin, you work with very, very large enterprises. I work with mid-sized companies mostly and also some startups like you do. And I have to talk to them about a whole gamut of digital assets including money. Like, “Do you have two factor authentication turned on for your bank account? What about QuickBooks?” Or whatever, your account packages, whatever. Whatever there. So yeah, it’s not just data. I just think of it as digital assets whatever those things might be. 

Wes Shriner: 

Nice. 

Torin Larsen: 

Absolutely. And the big companies have the same problems, honestly. And when you look at new vectors for social schemering attacks and things like that, it’s the same playbook regardless of the size. 

Wes Shriner:

So now we’ve got to transition. We know that we have data that we want to protect. But we’ve got to figure out how we as an organization, as an enterprise are going to protect that data. We’ve got to build consensus across the organization to protect that data and we’ve got to do it in a way that’s signed off by our officers and executed in every design decision that we do along the way. How are we going to do that? Ah, maybe we should have a security policy. Yep. Yep. Got my slide right there. 

On the left-hand side of this diagram is what everybody thinks security policies and standards are. You’ve got documents that turn into requirements, that turn into operations. It’s a three box set up. It can’t be that hard you guys. I mean, I do that in my sleep. It’s three boxes. The only thing that diagram is missing is beer cans and lightening bolts, but we can do that another day. That’s how we do network diagrams anyway. We’ll get there another day. 

But on the right-hand side of this page is actually the same diagram in greater detail as if you were a policy administrator trying to track the organizational security policy from the written word of my board of directors all the way down to what it looks like in ongoing operations in my production environment. And we’re going to get-

Kip Boyle: 

Yeah, this is inside baseball. 

Wes Shriner:

It is. It is. And this is Moneyball coming at you. This is all about what is my organizational security policy, what do those standards look like, what is prescriptive guidance? And then how do I deliver requirements or user stories? Which is actually the interesting way to go these days because our development teams are using user stories and we probably want to speak their language. If we’re going to drive requirements into their world, we probably need to do it in a language they understand. And that’s going to include implementation guidance, acceptance criteria and even the test cases that we want to use to demonstrate that that feature was enabled in the software as we asked for it. 

Then we’re going to risk management for things that didn’t quite make it. We’re going to do some traceability and accountability along the way, and we’re going to see it in production and that’s going to be a beautiful thing. It’s a lot of fun in a software team to see what you’ve done on the internet or in the world. 

Kip Boyle: 

Now, Torin’s here to keep us honest. And I’ve been watching his face. He hates this slide. Do you hate this slide? Or is it just mild-

Torin Larsen:

Well, actually no-

Kip Boyle:

is it mild disgust?

Torin Larsen:

No. No, [crosstalk].

Kip Boyle:

I’m really trying to zero in. [crosstalk], Torin.

Torin Larsen: 

I don’t hate this slide. I’m actually, I’m thinking about what Wes wants me to say when. But-

Kip Boyle: 

Just follow the script. 

Wes Shriner: 

Don’t hate the player, hate the slide man. 

Torin Larsen:

No, no, no. I think we’ll probably talk about this later, but I do really think there is a distinction between policies and standards as well as procedures, the prescriptive guidance. I will say one thing I don’t like about it, I don’t like the word guidance anywhere near a policy. I just, I want that to just … Guidance can be a lot of different things, but I very much prefer procedure or things like that. 

Wes Shriner: 

Maybe prescriptive light. Prescriptive path for the enlightened? Maybe we go with something like, right?

Torin Larsen: 

Sure. Guidance is just one of these things that people look at and they’re like, “eh.” The guidance takes the prescriptive away. Oh, it’s prescriptive, but it’s only guidance. So that just a term that I’ve never particularly liked. I-

Kip Boyle: 

It’s always set me up for failure. 

Wes Shriner: 

Is it too soft of a word?

Torin Larsen:

What’s that?

Wes Shriner:

Is that too soft of a word or too hard of a word?

Kip Boyle: 

They’re contradicting. 

Torin Larsen: 

Yeah. I mean, so as you say right here, policies need to be management’s, leadership’s assertion of what is expected for people to do. You can’t really expect people to patch their servers within X number of days if you haven’t written that down, because then they’re going to say, “Oh, I didn’t get to it.” It’s like you’ve point to something and say, “Well, it said so right there and this whole committee signed off on that.” So I mean, it is literally the definition of what you have to do. And if you aren’t doing it, then you’re not compliant and you’re not doing your job. Again, guidance I think can be good in some situations where it’s like, “Well, how do I do this?” That’s great. Implementation guidance I think is good if you’re giving them a set of choices. But I would almost put that off to the side, because right now it’s sitting between standards and requirements and for me guidance is more this helpful assistance that’s not required. And requirements are required because they’re called requirements. And standards are required because they’re called … So anyways. 

Wes Shriner: 

It’s near the-

Torin Larsen: 

Would you disagree? [crosstalk].

Wes Shriner:

It’s near the prescriptive guidance. I love it. We’re going to have a whole slide on that later, so let’s get there. That’s going to be a lot of fun. I think you called out a couple things that are worth calling out here. One of the common pitfalls is when you write security standards in a vacuum. That can be a real problem. Another one is when you write requirements for a project and you throw them over the wall to the project team and say, “Do something with this.” And you know if you send over a long document with a lot of written word requirements that aren’t specific to the project or the development build that’s being created, that’s not going to go in files one through 12. That’s going to go in file 13, the round one down next to the desk. That’s where that’s going to go. So we’ve got to get to a place where requirements are relevant speaking the developer’s, the builder’s language. 

Torin Larsen: 

Yep, absolutely. 

Wes Shriner: 

Okay. So let’s jump ahead and we’ll see if we can jump right into … Oh, sorry. Missed a slide. This is the slide that tells us we’re only taking on the top four items today. We’re going to take on policies, standards, guidance, and requirements. The reason for that is because those are the four areas that are actually done by the policy administrator. The rest of this diagram is part of the life cycle, but they’re done at different stages of the service catalog by different participants in the security organization and so we’re only going to cover these top four because that’s what your policy administrator and the policy service is all about. 

Kip Boyle: 

Props to you quote. Bruce Schneier. Love it. 

Wes Shriner:

Ah, go ahead. 

Kip Boyle:

Yeah, well I mean, I just wanted to affirm that we talk about technology all the time. Technology’s gotten us into the situation that we’re in. And we’re just looking for the next big blockchain, bitcoin gizmo to get us out of our problems. That’s just false thinking. So I just love this quote. I’m really glad you put it down in here. When I talk to CEOs and CFOs, they don’t understand technology anyway and what I’m telling them is like, “Look, you’ve got technology as a resource, but you’ve got people, you’ve got process, and you’ve got your own management team. Those are excellent resources and you should be tapping all of them and orchestrating them all to make sure that your digital assets are safe.”

Wes Shriner: 

Absolutely. And our quote for those that are following along at home is, from Bruce Schneier that says, “If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.” 

Kip Boyle:

It’s a good one. 

Wes Shriner: 

Thanks, all. All right, should we call it a podcast?

Kip Boyle: 

Oh yeah, that’s it. We’re out of here. 

Wes Shriner: 

No. We got more good stuff. Let’s take it on and see what we’ve got. Introducing the security policy. If we want to understand a little bit about the security policy, it’s going to guide all future security decisions made with the organization. It’s an agreement that the board makes with its customers, shareholders, stakeholders that this is what our promise is for how we’re going to treat your data. How we’re going to treat the things that you’ve entrusted to us. The assets that we’re accountable for. Once the board makes that commitment, that’s a public promise that’s made. And all the rest of this is working out that promise in our every day decisions in our organization. 

I pulled an actual copy off a security policy for encryption. So 800 Use Of Encryption. “Cryptographic controls must be used and implemented as per classification and encrypt standards. All cryptographic keys must be protected against unauthorized access, modification, loss, and destruction.” That is two sentences my friends about encryption, and that is the entirety of the security policy mentioning encryption. There is nothing more. Usually the security policy is about a two page document, maybe three with some extra fluff and signatures at the end. And its entire purpose is to set policy for each one of these areas. Anything you guys want to add to that before we jump into the working out of that policy in the standards?

Torin Larsen: 

Yeah, I mean, this can take a lot of different forms. When we say security policy, often times that can mean security policies, it can mean a policy set. It can mean an entire organizational chart of security policies. So it doesn’t have to be just one. I’ve seen a security program that’s the written security information program which is something that’s referenced by some regulations and that governs what different policies are. I’ve seen things where it’s tier one, tier two, that defines those types of things. 

Different organizations do them differently, but I think that the thing that I would say I’ve seen work versus not work, is as you referred to Wes, the smaller and the more straight forward the policy, the easier it’s going to be to manage in the longterm. I’ve walked into clients where they’ve handed me a 55 page security policy and it covers everything and it’s like, “Okay, when was the last time-

Wes Shriner: 

Is that policies and standards?

Torin Larsen:

Usually if it’s 55 pages. It usually has a mix of both. And it’s like, “When was the last time anyone reviewed and reapproved this?” And it’s like, “Well, probably when we bought it off the shelf five years ago.” Because the thing about policies and the way that I divide it up is usually security policies and security standards is I like to think of the security policy level statements as the thing that everyone else … Everyone can get onboard with. You can put it in front of the CEO and the CEO’s going to say, “That makes sense.” 

Wes Shriner: 

Yeah, we do that. 

Torin Larsen: 

And it’s funny because I use the same example that you put right here. When I’m explaining to someone for the first time how you do security policies, I say, a security policy statement is sensitive data should be encrypted. Or sorry, must be encrypted. And then what is sensitive data, what is encryption? Well, you go to your standards to define what those things are. How often do you need to make a change to the statement, “sensitive data must be encrypted”? Not very often. We’re going to agree with that most of the time. 

Wes Shriner: 

Right. Definitely. 

Torin Larsen: 

So the policy statements I like to say are the what and the … Sorry, the who and the what. So it’s assigning responsibility often times for so and so shall be responsible for this. And then the standards are more the what … Sorry, the what and the why and the who and the how. The what and the why, WW and the who and the how which sort of HH. Anyways, so you can tell. You can tell. Yeah, so-

Wes Shriner: 

It is late my friends. The sun has gone down-

Torin Larsen:

It is. It is.

Wes Shriner:

and Torin is a little loopy. 

Kip Boyle:

He’s a little punch drunk. 

Torin Larsen: 

So anyways. The difference though again is those high level statements are things that you can get a C level executive onboard with. It’s going to make sense to them. They’re going to agree with it and you’re not going to have to change it very often. The standard statements are the things that are going to get a little more technical. What kind of encryption do we want to have? I know I’m previewing your next slide, Wes, but what is what? A CEO is not going to say whether or not you can use what. But an encryption standard is going to have to go through what is the acceptable types of encryption and what are the unacceptable types. 

Kip Boyle: 

And you don’t want that stuff in your policy because it changes. 

Torin Larsen: 

Exactly. It changes more often and the audience is going to be different. And the people who are going to approve that’s going to be different as well. 

Wes Shriner: 

And that policy is signed up at the board level where standards are not. They’re much more localized approval. 

Torin Larsen: 

If you’re lucky. I mean, so at the board level you … So often times what you have is you have a charter at the board level and the charter says, these people are chartered to do your security and they have ultimate responsibility for security across the organization. I don’t care if you’re a product group, I don’t care if you’re an IT group, I don’t care if you’re a business group, that’s Wes, and he’s in charge of that. No debate, you’re done. And the board says that and Wes can go walk around the organization, wave that charter in people’s faces and say, “The board told me I could do this.” 

Wes Shriner:

And that’s always been effective in my career. Usually waving charters is the most effective way to win friends, influence people and create change from the middle or on the top in an organization. 

Kip Boyle: 

And have people throw parties in your name. 

Wes Shriner: 

Oh my. 

Torin Larsen:

You know it. You know it. Yep. 

Kip Boyle:

I just want to add one thing if I may. 

Wes Shriner:

Please. 

Kip Boyle: 

Is that I think of first of all I love the way Torin, I love the way you’ve explained it and I’m totally onboard with that. When I talk to my customers, sometimes they say, “Policies are just there and we don’t want them. They get in the way. We just want to do our job. We don’t want to be overly formal. And God, just the whole idea of policies just makes me shiver because it makes me think of the Department of Motor Vehicles or whatever. And so no, we’re not going to do policies. Everybody knows what to do.”

And so I have to tell the that policies don’t have to be like that. If you want to write a big thick policy set and wave it at the auditors like garlic to a vampire, and make them go away. Sure. I see people do that all the time. But you’ve managed no real risk. So I like to show them how they can actually create a policy that is flexible and useful. And really what I tell them, I say, “Look, you need some guardrails. You need some nice sturdy guardrails because you’re driving on a twisty mountain road. You need some guardrails.” 

Wes Shriner:

So I’m going to pick up from there, Kip. Thank you, that was thoughtful. We have used the term policy in two different definitions. One is the policy of these small documents signed off by the executive and then the other definition is the royal policy that includes all policy standards, guidance and anything else that’s related to the policy infrastructure. And so let’s keep that in mind as we go forward. We’re using it both ways interchangeably and it’s up to you the listener to guess which one we’re implying at the time.

Kip Boyle:

We have overloaded terms? That never happens in security. 

Wes Shriner:

Should be fine. 

Kip Boyle: 

Oh, I’m so sorry everybody. 

Wes Shriner: 

So let’s keep going. We have now established a policy. We need to work out that policy. Remember this was policy number 800, the use of encryption. Now we’re looking at security standards and we have a document number 810, 820 or 801, whatever you want to call it. And this is multi-page document that describes all of the workings out of our encryption expectations in our organization. This may have 10 bullets or it may have 200 bullets of those encryption expectations. One of those bullets might be confidential and restricted data must be encrypted while in transit within the organization’s networks and when transferred externally. The data classification standard would probably take us into great detail as to which kind of data is required to be handled in which way, but for the cryptography standard, this is a reasonable statement to expect. 

I want to call out a couple caveats in writing a security standard. The first is the MoSCoW method. MoSCoW is an acronym for must, should, could and won’t. Your policy statements usually have one of those four words. Your standards statements usually have one of those four words leading off. Data must be encrypted. Data should be encrypted. Data could be encrypted, or data won’t be encrypted. The other thing I want to call out on standard statements is they must be operational, not aspirational. If we are writing an aspirational standards, we are telling our auditors, we are telling our stakeholders, this is what we do. And what we mean is, this is what we’d really like to do. Why don’t you check our work and see that we’re not doing it. Don’t do that friends. 

Kip Boyle:

Gun meet foot. 

Wes Shriner: 

Right, that doesn’t end well, right?

Kip Boyle: 

Nope. 

Wes Shriner: 

Those policies and standards statements are also the working out of our agreement as a security team with our technology team that this is how we’re going to secure each of the assets in that technology space. And the value in that is once we’ve reached that agreement and managed that expectation, we can hold each other accountable to that and that’s where we get into that risk register and we start recording violations of our own policies and standards we’ve all agreed to as the risk register so that we can manage risk inside our organization. 

Torin Larsen:

I would add that goes back to your comment earlier, Kip, about IT policies saying … or IT people saying the policies make them skittish and stuff like that. Wes, is exactly right, it is-

Wes Shriner: 

Quote that. Can we get that in repeat mode. 

Kip Boyle:

I’m going to excerpt that. Just that little bit right there and I’m going to put it on YouTube as a highlight of the podcast. 

Wes Shriner: 

All 17 listeners, did you listen to it?

Kip Boyle:

We’re going to get 19 for that for sure. 

Wes Shriner: 

Ah, because your mom and my mom are listening. I love it. 

Torin Larsen:

But it’s true. When you set something in a policy, the person who had to implement that policy should have the opportunity to say, “That’s not possible. We’ve got a 30 year old mainframe and you can’t do that there.” And there should be an opportunity to have a back and forth to say we’re setting this policy. Oops, it’s not going to work here, what are we going to do about that?” And if you don’t have that back and forth, if you don’t have that agreement that Wes is talking about, then IT and security and all the other different constituents are going to be on different pages about what we can do, how we build a system, how we manage a system. And-

Wes Shriner: And then you’re going to have angry peacock neighbors. 

Torin Larsen:

And when something goes wrong, guess what’s going to happen. All hell’s going to break loose and we’re going to find that everyone’s pointing this way because no one was actually in agreement on how something should be done. 

Wes Shriner: 

Wow. And there we go, we can end there. No we can’t. There’s more to do.

Kip Boyle: 

Jump ahead. 

Wes Shriner:

If we’ve got an aspirational policy and we want to include it still, we can set an as of date. We can set a date six, 12, or 18 months into the future and say, “We shall” … not we must, but we shall … “achieve this standard of security or quality of service as of this date.” So that’s one-

Torin Larsen: 

And you can-

Wes Shriner:

to handle it. 

Torin Larsen:

You can essentially phase it in too. All new systems shall have this feature by this date. All legacy systems shall have this feature by that date. And give yourself more time to deal with it. And then there’s also other things that come into it. No policy structure is worth anything if it doesn’t have an exception process. So you’ve got to have a process to identify and manage, accept risks as part of an acceptance process, or an exception process. And-

Wes Shriner:

Please don’t call it an exception process. 

Torin Larsen:

Okay, I’m sorry. [crosstalk] I’ve always called it. 

Wes Shriner: 

Please. They’re not risk exceptions.

Torin Larsen: 

What’s that?

Wes Shriner: 

We can accept risk, but-

Torin Larsen: 

Yes. Yeah, I spoke wrong. Sorry. Sorry. A policy exception must have a risk acceptance process. [inaudible], right? Did I get that right?

Wes Shriner: 

Well done sir. I think that’s what you’re saying. 

Kip Boyle: 

Yep. Sandy sells sea shells by the seashore.

Torin Larsen: 

Yeah. Exactly. Yes. 

Wes Shriner:

It’s late of Kip, we’re after his bedtime. This is going to be a good second half of the podcast. 

Kip Boyle: 

Oh, for sure. For sure. It’s after my bedtime. Keep going. 

Wes Shriner: 

Oh yeah. All right. So I’ve got a special guest speaker for us today. Let’s see if he can tell us something. 

Justin: 

Why? Why would you put a procedure about managing firewalls inside your user access control policy? Why? Make your auditors happy. Make sure your documentation is organized. 

Kip Boyle: 

He dresses like all the auditors I see. 

Wes Shriner: 

So Kip, be nice to him. He’s my actual auditor right now on an existing audit. So be nice to him please. 

Kip Boyle: 

Justin, I really appreciate that you made a drop in appearance man. I’m going to buy you-

Wes Shriner: 

Isn’t that tremendous?

Kip Boyle:

Yeah, I’m going to buy you a beer. This is great. 

Wes Shriner: 

I’m hoping Justin the angry auditor drops in again for us on other topics, because he’s got a lot of good stuff to say. 

Kip Boyle: 

I think we could convince him to do it. 

Wes Shriner: 

We talked about one security standard, the encryption security standard and we called it number 800. Well, there’s actually 20 common security standards that you might see in your enterprise and here’s a list of many of the common security standards. NIST offers more details and specific standards templates that you can start building from. These are just some expectations for what you might see in a security standard library. I want to call out a couple examples. The identity standard, likely includes both standard and privileged user expectations. It probably has access definitions for both premise and cloud applications and it likely includes standards for both interactive and non-interactive accounts. 

The risk management standard likely has the agreed upon risk criteria that will be applied to any security risk findings and what level of the organization can accept what type of risk. If we have a well organized security standards, than Justin the auditor is going to be happy. Never happy. He’s Justin the angry auditor. But we’re also going to be able to update maintain and find the standards when we need them in our organization. So structuring your standards in a way that you can look it up again later is excellent and a good practice to follow. 

Torin Larsen: 

Which of these would you wager you spend the most time on?

Wes Shriner: 

Updating or the most time on-

Torin Larsen:

If you’re drafting from-

Wes Shriner: 

referencing?

Torin Larsen:

If drafting from the beginning. 

Wes Shriner: 

I think you could tell us that better than I could. I spent a lot of time hitting the data classification handling, because a lot of what I do is consulting inside the organization about well, what kind of data are you manipulating and where do you want to send that? Are you sure you want to do that? You want to send customer data over the internet, should we talk about that?

Kip Boyle: 

I think it’s a trick question. 

Torin Larsen: 

No, I mean-

Kip Boyle: 

I think Torin just asked a trick question, because-

Torin Larsen:

only in that it’s at the very top of the list. But go ahead, Kip. You were going to say together. 

Kip Boyle:

Yeah, yeah, yeah. No I was going to say, it’s a trick question because nobody in their right mind writes a policy from scratch. We shamelessly steal, oops, borrow, plagiarizer. Nobody starts from scratch. Charles Cresson Wood made an entire career out of giving us a whole thick book of cribs. Did you ever look at that Security Policies Made Easy?

Torin Larsen:

I’ve never used that, no. 

Kip Boyle: 

It’s an 800 page book full of stock security policy statements that you can just thumb through and pull out the ones you like, man. 

Torin Larsen: 

Even if you do that, I guarantee you will … And if you have anyone paying attention, you will spend the most amount of time on the acceptable use standard. Because of these, it’s the only one that is facing every employee in the organization. All the rest of these here and al the other ones that aren’t listed here are going to be ones that different people in IT are going to grab for different purposes. Obviously the auditors are going to grab them and stuff like that. But the acceptable use policy in my experience is always the most contentious because that’s the one that you attach to the security awareness and they have to sign their name on it and that is the one that HR is going to want to thumb through. In every little last bit of detail. And there’s always some wrinkle to every little thing that in there. 

Kip Boyle: 

Oh, I so agree with you. I so agree with this point. And the HR angle is particularly relevant because as a manger, if I’m going to hold somebody accountable because they violated the acceptable use standard, then that means I’m going to HR and I’m invoking the disciplinary process, whatever that looks like, and I’m getting support from the human resources department, for holding somebody accountable for what they’ve done. So yeah, makes sense. 

Torin Larsen: 

Generally legal wants to see it too. Yeah, and the other thing that I didn’t say before when I was talking about the difference between the audiences for policies and standards, if you’re implementing a program like this for the first time, one of the other reasons that you do policies at a high level and then you do standards later a low level, is that generally by the time you’ve gotten through the policies, all the executives who thought they were going to be super involved are really tired of it at that point. And then when you move onto standards, they don’t even fight about it. They’re like, “Oh okay. That’s a different level of authority. Sounds good. I’m glad to be done.” But again, they’ll be all over that acceptable use standard and so if it’s a policy, often times it’s called an acceptable use policy. It depends on what you want to do. But no matter what, you can’t bury that one in a standard. It will be something that everyone will want to be involved in. 

Wes Shriner:

Nice. All right. So we’re going to take that standard and we’re going to jump into Torin’s favorite topic prescriptive guidance. You can also call it hardening guidelines. You can call it security procedures. You can call it detailed requirements. These are implementation and changes to how do you deploy in our environment. This might actually be here is the requirements for what should go in my chef puppet recipe, pick your chef, pick you puppet, pick you automation tool, for how I’m going to build my environment out and set my gold standard for server builds. 

Torin Larsen:

I would argue, Wes, at least in my experience that the example here … I mean, I think it’s okay when we’re saying PEAP or EAP-LTS. That’s okay. But I would argue that some of this really should be in a standard instead. Again, in prescriptive guidance, I don’t feel like people are going to be … So again, WPA must not be used for any wireless encryption. For me that’s not guidance, that’s something you need to lay down in the standard, because people won’t take it seriously in prescriptive guidance-

Wes Shriner: 

True. 

Torin Larsen: 

and that’s where I have the issue with the term, is guidance doesn’t sound like … So it’s like, “Oh, well the guidance told me I shouldn’t use WPA, but I’m going to do it anyways because I’m a total idiot.” 

Wes Shriner: 

No, I’m just kidding. So I’m not going to disagree with you. I’m going to say that policy is signed off at the board … Oops, sorry … standards are signed off at the executive level inside the company. Guidance is signed off by some manager in building three. Guidance can be written by anyone and recorded and changed on the fly with very little administrative overhead. And so because of that, it may be that we get statements that are standards based statements appearing in our guidance as well. 

Torin Larsen:

And so for as an example again, I’m really talking about this specific issue on this specific example, but for example, I would be when it comes to hardening standards, I mean, I would typically have a policy … Or sorry, I would have a policy that says all systems must be hardened according to industry guidance. And maybe defines what that means or something. But in the standard, I would have something that says, “There shall be secure configuration procedures” … prescriptive guidance, whatever you want to call it … “and those procedures must be based on either CIS or NIST.”

And then every procedure must use that as a baseline and there must be traceability between the CIS or NIST standard and what we chose to implement from that standard versus what we chose not to. And then you can hand it off to a procedure and you can have Joe manager approve that procedure. And again, that will change frequently. New ones will be added frequently. But I guess, and I’ve seen PCI auditor harp on WPA a lot and stuff too, so that’s where this example I feel like some of that would be helpful to have at the standard level so it would be a little more mandatory. Would you disagree?

Wes Shriner:

I would not, and I’ll buy that for a dollar. And then I will say the easy button for prescriptive guidance is look at … you already alluded to it … the NIST standards. We can go grab the STIGs which is the Security Technical Implementation Guides, the U.S. government publishes for many platforms that are available in the marketplace today, literally telling you, this is how if you’re going to do business with the U.S. government we want it configured to be configured securely. We can apply those in our environment as well. We can grab the STIG. It’s free and fully available to you. So use it. 

Kip Boyle: 

Yeah, and if you’re studying computer security and you’re trying to understand what are the various settings that are available that are possible, that are actually recommended to be turned on. Just go start reading these things. I mean, just go grab them and start going through them. They are wildly educational. They’re not fun to read, right. I’m not saying that it’s fun, but it could really help you understand what’s the landscape on all these technologies. 

Wes Shriner: 

If you thought we were putting you to sleep, those STIGs are going to be awesome for you. 

Kip Boyle: 

Oh, it’s like reading the encyclopedia. I’m not saying it’s fun, from cover to cover. 

Wes Shriner: 

All right. 

Kip Boyle: 

Well, I guess we don’t have those anymore. Ah, dang. I need a new metaphor. 

Torin Larsen: 

So if I can diverge to a side note right now, since we’re just talking about this. I just wrapped up this project where we’re doing these assessments of manufacturing organizations in Asia, and a lot of them have a basic IT function, but really nobody has any concept of security. And one of the things we’re asking about it hardening. And we’ll ask the question, are you doing system hardening? And they will say, “Yes, we are.” And we’re like, “Okay.” The question I like to ask is, “Okay, how long is your hardening procedure for a given platform?” And they’ll say, “Two pages.” I’m like, “Nope, you’re not doing hardening. So here, I will send you a link. This document is 130 pages long, this is what hardening is.”

Kip Boyle: 

You’re just using a big font. I know you. This is just tricky.

Torin Larsen:

Yep. 

Wes Shriner:

Nice. All right. So that brings us to the bottom of introducing policy standards and guidance. To wrap up and really drain all the goodness out of security policy services, of the service catalog, we’re going to jump into, what is the inputs process and outputs we might expect in a policy administration process. And we start with who are our suppliers. Our suppliers could be our development teams. It could be our infrastructure teams. It could be our own business teams. It could be our executive management. It could be out board. Suppliers for what policy we should have can come from anywhere and they feed into the policy backlog. 

As I was brainstorming at midnight last night, some of those policy backlog items might come from new technologies or new solutions. It might be a new threat or a new vulnerability come up in the marketplace. A new policy backlog item might come from a miscommunication or an argument in the organization. If your peacocks are making too much noise, there might be a long discussion that turns into we need to codify this discussion with a policy statement so we don’t have to argue about it in the future. Other places policies and standards come from is arguments about what is right. Or even better, great ideas from management. So those are the places we see policy backlog come from. 

The policy administrator takes all of that backlog, incorporates it into draft documents. Notice I didn’t say the policy administrator brainstormed all of these things. They collected them and they built consensus and then the created drafts that then could be reviewed by various parties. They tracked those draft reviews. And then deliver them as final reviews for sign off. If we think about a SIPOC, a SIPOC is the supplier’s inputs processes, outputs and customers. Who are the customers of this are actually the same group that was the suppliers? It’s almost a dynamic circle of codifying how we are going to do business and then doing business that way. If you’re interested more in the SIPOC process it’s a Six Sigma or a Lean term, if you’re going to go deeper into total quality management. All right. Anything guys you want to add here?

Torin Larsen: 

Wes, I thought of another one. And more common at large organizations, which is reorgs. 

Wes Shriner: 

Tell me. 

Torin Larsen: 

No. Reorgs. I mean, when an organization reorgs, all the again, what I talked about the who and the how, all changes and you have to reassign who does what and to what level they do and, oh this other organization did it differently and all that kind of stuff. And there’s policy implications for that type of thing. And sometimes there’s total tear downs involved. 

Wes Shriner: 

So what kind of gotchas do you see in this policy administrator process? Torin, you have written or supported 100 different policies in the Greater Puget Sound. What gotchas do you run into?

Torin Larsen: 

Well I don’t know if there is a 100 different organizations, but I’ve support a lot. Again, most of what I’ve done has been standing it up from scratch. So the gotchas are usually around how do we do this. And it’s the chicken or the egg argument. Do you write the policy the way it should be or do you write the policy so loose that it doesn’t have any meaning or value to it? If you write the policy to be … We’re talking about the whole aspirational thing, if you’re writing the policy to reflect how it is today, in a lot of cases for a lot of organizations, that’s a pretty worthless policy. If you don’t have policies to begin with, chances are you also have a lot of other gaps and you don’t want to write all those gaps into your policies. 

Wes Shriner: 

No. 

Torin Larsen: 

So then there’s, to be honest with you, these projects end up being really challenging because there’s a lot of negotiation involved. And there’s a lot of, is this even your job? You’re not allowed to do that. We can’t do that. That’s going to take $5 million, and those types of things. And as we talked about earlier, a lot of that it becomes a negotiation over implementation timeframes, the difference between new systems and legacy systems. Okay, there’s an exception process, you can follow the exception process. Oh no, I’m sorry you can’t approve your own exception, we’re going to have to approve that for you. And there’s also a lot of education involved. There’s a lot of handholding. There’s a lot of we’ve never done this before, what are you talking about? And then you bring in regulations to it and there’s a lot of, okay, we have to ISO and HIPPA and SOC2 and government-

Wes Shriner: 

DCI and GLBA. 

Torin Larsen:

Yes. Yes, exactly.

Kip Boyle: 

You had a slide on that. 

Torin Larsen: 

Earlier, yeah. Yeah. But there’s different constituencies involved in that often times. And they will have it out as far as what they need versus what other people need versus what other people don’t want to have to do. And so there’s a huge amount of this … everything in the slides here that we’ve talked about feels very quantitative and very black and white. And in actuality, when you go and implement a whole policy program for an organization, it is nothing but qualitative. It’s all negotiation handholding, arbitration of points of view and all that kind of stuff. If anyone’s paying attention. If nobody’s paying attention, then it actually goes very smoothly and you just write all the policies, they click approve and you’re good. 

Kip Boyle: 

That’s-

Torin Larsen: 

But if [crosstalk] is actually paying attention, it is a very thorough and painstaking exercise. 

Kip Boyle:

If no one is paying attention, you know what you’ve just done is created auditor begone. Yep, that’s all you’ve done. You’ve just-

Torin Larsen:

But then there’s a danger in that because it’s probably not accurate. And people probably aren’t going to pay attention to it. And down the road they’re going to implement things that don’t conform with policy and the auditor is going to find that and you know. 

Wes Shriner: 

So I’m glad we kept going earlier, because I think the last two minutes was the most important part of this episode and I’m really looking forward to capturing that in this next slide here that talks about what are we looking for when we talk about the roles inside the policy administration service. There’s really only one role, it’s the policy administrator or team of policy administrators. That can be a junior person, a senior person, or it can be a principal level contributor. 

This is very much a business skill service. This is all about technical writing building consensus and creating it and following attention to detail. We just heard Torin describe that job in the greatest detail I’ve ever heard anyone describe it and I thought it was phenomenal. I hope you rewind and listen to him again on that part. The most common tools used here are Outlook, SharePoint and Word. We’re doing change tracking and we’re doing notes. This is a business job inside security that is absolutely critical to security, and you don’t have to speak DOS. 

Kip Boyle: 

Yeah. And maybe there’s a GRC tool you have to use too, right?

Wes Shriner: 

You could end up loading your policy statements into the GRC tool as part of the integrated controls in GRC.

Kip Boyle:

But it’s not that complicated. It’s not that tough. 

Wes Shriner: 

No, very manageable. 

Torin Larsen: 

But depending on the size of the organization, there can be payoffs to that. So Wes and I worked on a project where we after some work to get things aligned and rationalized and stuff like that, we basically created a system by which from the project intake process, when a project was being first in the concept phase, it could be in-taked into a system based on a questionnaire and set of criteria and stuff that would take the policy statements, those would boil down into standard statements, would boil down into security requirements. The security requirements would be matched to the project profile based on the answers to the questionnaire, and then that flowed into, on that chart that Wes had before, that flows into user stories, which then flow into test requirements, which then flow into testing results.

And for a large organization that does a huge amount, that has hundreds and hundreds of software developers doing a huge amount of software development, that can have enormous benefits in terms of ensuring the security act … ensuring the policy intentions make their way into the end product. And again, ultimately, making your systems secure, passing those audits, all those kinds of things. All that good stuff. But I mean, you say a GRC tool, I mean, that was something, I mean, Wes we were developing and I think we developed five different microservices that integrated the profiling app with the GRC app with the test requirements repository and all those types of things. So you can get very complex here and there’s a payoff to it, even with all that effort.  

Wes Shriner: 

But I wouldn’t expect any common policy administrator to be at that level. That was a phenomenal and very fun project. I think we should bring that forward to this conversations some day in the future. We should have written the white paper then, but we’ll write it now. And it’ll be fun. It was a really cool project of creating security user stories early on when security users stories didn’t exist yet. So that was really fun. 

Torin Larsen: 

Right. 

Wes Shriner: 

When I think about this policy administrator, it’s often a role that is not pursued in the security organization. It is rarely one that people transfer into by choice. Sometimes we find ourselves there. It’s the last person left, I ended up helping with it and now it’s my job. And sometimes that’s how it works out. But I would call out that I think there are whole careers that can be made around a person who embraces policy administrator and becomes the policy administrator for an organization or for several organizations and it’s a powerful and strong and healthy career to have. 

Torin Larsen: 

And I think those roles also often times, I think one of the things that might appeal about that type of role is that often times that person is also responsible for shepherding through, again, the exception process, and the risk acceptance process. Acceptance. And it-

Wes Shriner:

Sometimes. 

Torin Larsen:

actually can mean someone who’s relatively in the weeds on policies and maybe early in their career might get a lot of executive focus. Where if you have the right skillset to be able to explain to an executive what the gap is, what the associated risk is, what we’re doing about it, what the residual risk is, and given all that stuff, do you want to approve this, that role has a nice executive exposure that I think is going to be appealing to some people. I’ve seen that role also have a piece of managing a steering committee. If you’ve got a security steering committee or a policy committee or things like that, that person might be the person who coordinates those things. And coordinates those meetings and the discussion of risk and all those kinds of things. Again, lots of nice executive exposure as part of that. 

Kip Boyle: 

Yeah. Yeah, yeah. Yeah, and you’re going to build some really good mental models for how this stuff really works. Which you can then take with you if you’re going to move on to another assignment in another part of the org.

Wes Shriner:

And that’s what a lot of people do, but my call out is actually this could be a career opportunity. It’s possible to make an entire career out of this and have a great 9:00 to 5:00 business job opportunity and be excellent at it and actually sell those services to more than one company, right?

Kip Boyle: 

Yeah, definitely. Now, Wes, I-

Wes Shriner: 

And you don’t need … And you can do it straight out of school. 

Kip Boyle:

 I know the guest gets the last word. 

Wes Shriner:

Ah, they do. 

Kip Boyle: 

But I want to say something before the last word. 

Wes Shriner: 

All right. 

Kip Boyle: 

Okay. So you had asked Torin a moment ago about what’s the hardest part I think of all this. And from my point of view, as a CISO, the hardest part is operationalizing it. 

Torin Larsen: 

Yes. Yes. Absolutely. Absolutely. 

Kip Boyle: 

If it’s not well written, can’t operationalize it and it means nothing. 

Torin Larsen: 

Yep. Yep. 

Wes Shriner: 

And then you have Justin the angry auditor. We don’t want that. 

Kip Boyle: 

Right. Right. 

Torin Larsen: 

Well, and a tangent to that too is edge cases. The operationalization of it is always … the challenge is always an 80/20 type thing. It’s pretty straight forward for your core systems, it’s the edge cases that kill you. 

Kip Boyle: 

And that’s what you need an exception process. 

Torin Larsen: 

Yep. 

Wes Shriner: 

Out standing. 

Kip Boyle:

Okay, there.

Wes Shriner: 

All right. 

Kip Boyle:

Let’s do it. Let’s keep going. 

Wes Shriner:

So I’d love to give Torin the microphone. Tell us, Torin what have been the keys to your success in your career?

Torin Larsen: 

So I thought this was funny, because I appreciate it I guess, there’s an implicit I’ve been successful in that question, so thanks. 

Wes Shriner:

Go with it. 

Kip Boyle: 

The fact that you’re here-

Wes Shriner: 

I respect you. 

Kip Boyle:

The fact that you’re here, we declare you successful. 

Torin Larsen:

Thanks. 

Wes Shriner:

I respect you, man, you got this. 

Torin Larsen: 

Aw. So I mean, I think I’ve to some extent stood on the shoulders of others as they say. Or I think there’s no one person who can know everything about security. And so there’s just too much out there to know. You’re never going to be a specialist in everything, so I think the keys to my success have been the people that I’ve been able to partner with. The people being on my team. The partners, the great clients that I’ve been able to partner with and stuff like that. The relationships that we’ve had. The resources of a network in a community to be able to go out. I mean, I don’t take credit for any of my own knowledge. What I might take credit for would be my ability to cordon the resources that I have and bring those to bear on an outcome that’s going to make my clients successful. And I mean, that’s where I guess I see the secret sauce of my success, but really what that comes down to is all the good people I’ve worked with and the great clients that I’ve had and the experiences that those have all brought to me. So yeah, again, it’s this-

Wes Shriner: 

So you’re the orchestra conductor and you don’t play the clarinet, but you have the right clarinet player at the right time and you’re able to draw them out, and that’s a tremendous skill in itself. 

Torin Larsen:

Yeah, and I was almost thinking, I’m the baker and it’s really about the ingredients. And I’m able to substitute ingredients and bring the right combination of them in, but it’s really the ingredients that makes the bread really good. I don’t bake at all, so I don’t know if that’s a good analogy or not. But anyways, the real point is it’s a team sport and you’re only as good as your ingredients or your team or whatever analogy you want to use. 

Wes Shriner: 

Just know that bread rises at different levels based on where you’re at in the country. If you’re up in Denver a mile high, it’s going to rise at a different rate than if you’re down here in Seattle at sea level. So as you’re baking your bread across the country just keep that in mind. 

Kip Boyle:

Life on the farm. 

Wes Shriner:

Right. 

Torin Larsen: 

Does that make Seattle better or worse than Denver, I’m not sure. 

Wes Shriner: 

It just means it rises at different rates and you’ve got to plan your day for it. You’ve got to get up earlier in some parts of the country to leaven the bread. 

Kip Boyle:

Now I’m hungry, I want bread. 

Wes Shriner: 

What have we got for, if you were talking to little buddy, little brother, little sister, what would you tell them to focus on in their cybersecurity dreams?

Torin Larsen: 

I mean, I think so I always, in my role that I’m in, I often get younger people out of school who are coming to me saying, “Hey, security sounds cool. I’d like to do it.” What I encourage them to do is really ask themselves what they’re actually interested in and what’s driving them to do that. And there’s lots of areas within security. There’s lots of different disciplines. There’s technical aspects of security. There’s non-technical aspects of security. I would tell them to follow their curiosity. I think the most important thing in being successful in security in the longterm and really driving your career is having a good curiosity. 

And again, your curiosity might be a technical curiosity, it might be a non-technical curiosity, but I see a lot of people try to push themselves into security because it’s a good career track or job security or pay or whatever the rationale is. And that’s not going to be enough to get you there. So you’ve got to find something in the realm of security or privacy or whatever you chose to go down that’s going to bring you there. Because the learning curve is high and the industry moves fast and you’re always going to have to learn new things. And it’s hard to keep up honestly. So I think the key to that is curiosity. And tailor your path. Tailor your area of focus to what naturally makes you curious and interested. 

Wes Shriner: 

Nice. 

Torin Larsen: 

You can’t force yourself into it. 

Wes Shriner:

I hope that today’s policy episode actually inspires some people to chose policy administration as a career choice, at least at some point in their career. And I hope that we’ve enabled them to do that because maybe they saw themselves in that role in the future. 

Torin Larsen: 

I mean, again, if you’re great at explaining something to people, if you’re great at talking to executive audiences, I mean, it might be a really good fit. 

Kip Boyle:

If you have the heart of a teacher. 

Wes Shriner: 

Building a consensus. 

Torin Larsen: 

Yeah. Yeah. 

Wes Shriner: 

You’ve got it. All right. So what do you know now that wish you knew then? 

Torin Larsen:

Yeah. 

Wes Shriner: 

What’s that one?

Torin Larsen:

Without question, just go Google stuff. Don’t let things go in one ear and out the other. The number of meetings I sat in early in my career where I’d hear something, there are more experienced people than me around and I’d hear them say something and so like, “Okay, whatever.” And I’d just let it fly. At some point in my career I realized I should be keeping a list of those things and after the meeting going and Googling those things and figuring out what the heck those people were talking about. And there was a turning point in my career when I started doing that in terms of my learning curve. And how quickly I absorbed information and stuff like that. I wish I knew how valuable that was earlier on. It took me too long to figure that out frankly. And I think that’s a skill or a habit everyone should have. 

Wes Shriner:

So I’m going to call you on that one Torin, because Google was invented in 1998 I believe. 

Torin Larsen:

Yeah, but see I didn’t start the practice until 2007 or something. 

Kip Boyle: 

You had to let Google ripen. You couldn’t just go use it. 

Torin Larsen: 

Yeah, right. Right. I had to Metacrawler that a little bit at one point or Lycos or-

Kip Boyle: 

AltaVista. AltaVista. 

Torin Larsen:

AltaVista, man. Yeah. 

Wes Shriner: 

Out standing. So don’t let these terms fly past you without taking the opportunity to be curious and look them up. I hear a real theme of curiosity from you and that’s how I’ve known you as well-

Torin Larsen: 

[crosstalk].

Wes Shriner: 

and I think that’s one of the things that makes you an interesting human being, because you’re curious about all the folks that you encounter. So that’s pretty cool. 

Torin Larsen: 

Thanks, Wes. 

Wes Shriner: 

Thank you for being our guest here today. If I were to close us out, I want to take us to our final thoughts. Our key takeaways are that policy is the beginning of security. You can’t have a security organization unless you have a security policy that sets the direction and tells you where you’re going. And policy administration is more involved than most people think. In fact, I think there’s a whole career that can be made out of it. I’m looking forward to next week where we take that policy and we start to apply it to our security strategy and architecture. It’s going to be a fun conversation, I hope you come back and join us. Over to you, Kip. 

Kip Boyle: 

Excellent. Yeah, so let me bring it home for you. Well, if you’re still here. Congratulations and we appreciate it. 

Wes Shriner:

Yes. 

Kip Boyle:

And it means you like what we’re doing, which that’s just fantastic. Well, if you do like what we’re doing here, we’ve got a free PDF for you, it’s a guide. It’s called Play to Win, Getting Your Dream Cybersecurity Job. What we’ve done is we’ve taken the whole idea of capture the flag and we’ve borrowed that and we’ve turned it into if you can go do capture the flag then you can get your dream cybersecurity job by actually using those skills to hunt for your job. Don’t just sit around waiting for jobs to role in in your email box. Actually go out there and find them. Find an internal champion in the organization that you want to be a part of. Build your relationships and get your dream job. It’s about 20 pages, super visual. You can see in this slide on right here in the video, there’re pages six and seven. Anyway, if you want to go grab it, just go to yourcyberpath.com/pdf, yourcyberpath.com/pdf and let me know what you think of it. If you think it stinks let me know, then I’ll change it. Tell me what you think. 

But that does it for this episode. You’re just one path away from your dream cybersecurity job, don’t forget that, but we’ll see you next time. 

Wes Shriner:

Thanks all.