Home

Search
Close this search box.
EPISODE 32
 
Cybersecurity Service Catalog & Your Dream Job
 
EPISODE 32
 
Cybersecurity Service Catalog & Your Dream Job
 

CYBERSECURITY SERVICE CATALOG AND YOUR DREAM JOB

About this episode

In this episode, we are diving deeper into the roles in a typical cybersecurity organization. There are several jobs available out there and not all of them are entry-level. We will help you define which jobs you might want to target for entry into the cybersecurity industry in this episode.  The common security service catalog contains 23 common services performed in a large security organization. The service catalog is one of the mechanisms used in IT service management (and ITIL) to list the different services and products offered by a given organization to their internal or external customers. By understanding the services and products offered by your organization, you can better understand the skillsets and positions required to fulfill these services.  During this episode, we also cover the topic of the reporting structures used in a large security organization. This includes how reporting is performed, why it is important, and the type of language used when doing the report.

What you’ll learn

  • What a service catalog is
  • What common services are offered in a service catalog
  • How reporting is performed done in a security organization

Relevant websites for this episode

Other Relevant Episodes

  • Episode 30 – A Cybersecurity Job That Fits You Like a Glove
  • Episode 31– All the Jobs in a Large Cybersecurity Organization
  • Episode 65 – How to best prepare for a role in the SOC

Episode Transcript

Kip Boyle: 

Hey everyone. This is Your Cyber Path. This is the podcast that helps you get your dream cybersecurity job. I’m Kip Boyle. Wes Shriner’s here with me. We are experienced hiring managers of cybersecurity people, and we are here to share with you what we know. And today we’re back with our second video podcast ever. So, if you’re listening only to us right now, then you either forgot or you didn’t get the message that we have a video version of our podcast, which you can go watch. And it’s called Your Cyber Path podcast.

If you search for that on YouTube, you’ll find our channel and you’ll be able to actually watch us. And that’s important because we are doing a tour. We’re actually giving you a tour right now. We’re in the second of three episodes where we are sharing with you how a cybersecurity organization is typically put together. We’re doing this because we want you to know all the different types of jobs that are available, and there are a lot of different types of jobs. Not all of them are entry level. Only a small percentage of them are first time cybersecurity jobs, but you really need to be thinking about what are you going to do next? And so that’s what we’re trying to do here is we’re trying to paint a very big picture for what is possible for you. So having said that, without further ado, Wes.

Wes Shriner: 

Wes, it’s good to be here, Kip. I’m glad we’re getting a chance to jump into this. It’s going to be interesting, good stuff.

Kip Boyle:

Yeah, for sure. I’m going to take a sip of my tea and I’m going to let you keep going.

Wes Shriner:

All right. Well, I’ll tell you that we’re on a new journey and a new video. Thank you for joining us. If you are listening by audio only, this might be a great day to move to video because we are going to have a presentation that I think will really enhance your understanding. We’ll try and cover it from audio. But if you get a chance to catch the video later or download the PDF slides later, that would be the way to go. We’d recommend that.

Kip Boyle:

And the way you’ll know to download, yeah… So to watch the video go to YouTube, but if you just want to download the slides, look for the URL in the show notes, and you’ll be able to retrieve them.

Wes Shriner:

Indeed. All right, today, we’re going to cover what is a common Security Service Catalog. What are the 23 common services to that common Security Service Catalog? What is a common reporting structure for a large security organization? And we’ll set a roadmap for where we’re headed from here.

Kip Boyle:

Perfect.

Wes Shriner:

Should be a lot of fun.

Kip Boyle: I don’t know, dear listeners, if you’ve ever heard of a Service Catalog, but it’s part of the jargon so let’s define that.

Wes Shriner:

You’ve heard it said, “I don’t even know what they do over there.” The Service Catalog is really how we define what it is they’re doing over there, right? It’s a list of services the group offers, right? It’s inputs, processes, and outputs, your SIPOC. System, inputs, process, and outputs.

Kip Boyle:

SIPOC. Man, throwing the jargon around like crazy today. Okay, keep going.

Wes Shriner:

Well, if you recognize the jargon and you can apply it appropriately, it’s going to help you along the way.

Kip Boyle:

Yeah, you do need to pick this up.

Wes Shriner:

If you don’t know that word, do it at Wikipedia. Just go learn it. It’s worth doing, right? It describes what we build, what we do, and what we deliver. And it’s really like an order by number menu. So let’s jump in and see what security services are in a Security Service Catalog.

Kip Boyle:

All right, flipping the slide.

Wes Shriner:

We’ve seen this slide already. This came from us last week. It has the primary cybersecurity organization. It has four organizational units, and then it has the 14 disciplines around it. 14, 15…

Kip Boyle:

And very helpfully color coded.

Wes Shriner:

Color coded.

Kip Boyle:

You can find your way around.

Wes Shriner:

All right. Now I want to introduce the 23 services to a common Security Service Catalog. These 23 line items are the common services of a large security organization and they work in every security organization, and everything the security group does can likely be tied back to one of these 23 services.

Kip Boyle:

Got it.

Wes Shriner:

I’m not going to drain all these services at this time. I do want to point out that we’ve got some skipping in numbers and that’s on purpose. 1 through 8 are your Operational Security, 10 through 15 are in your Engineering, Architecture, and Test. 20 through 25 are going to be in Governance, Risk compliance, and the 30’s are going to be your Product Security. We’ve intentionally skipped some numbers because these things change over time. What we, as a security organization did five years ago has changed. [crosstalk] We’ve added and removed services every year since it started walking through this. So, it’s going to continue to grow and morph and become better over time. So let’s see if we can overlay these 23 services on top of our organization. Oh, look at that.

Kip Boyle:

Turns out you can.

Wes Shriner:

Turns out you… Who knew? This is cool.

Kip Boyle:

You knew. You knew so all along because you built these slides.

Wes Shriner:

I do want to point out that this is not a one to one relationship between the organization and the services provided. You’ll see there’s some overlap. There’s some gray area in the there where 13 is covering two different disciplines. It’s because that’s kind of how it works sometimes, right? It’s not a linear discipline to Service Catalog in every case. But all disciplines support Service Catalogs, and all work we do is usually rolled up under one of our services.

Kip Boyle:

And you know, Wes, in my experience, I have rarely actually seen the Service Catalog printed and posted and something that I could actually thumb through or look at. Usually what I see is an org chart. And then I kind of have to, by looking at the names of the organization units, I kind of have to squint and go, “I think that’s what these guys are doing.” And if I go to them, I can actually say, “Well, do you do this? Do you not do this?” That’s how I’m used to discovering what services are offered, is just by going to the people in the different units and asking them. But I don’t know, have you actually seen it documented any way like you’re showing us now?

Wes Shriner:

This is the first time I’ve seen this documented this way. I know that some organizations do build out their Security Service Catalog and I have seen a Security Service Catalog. In fact, I’ve seen the services mapped with inputs, process, and outputs to each other so you can follow linearly through the organization as well. That is not what we’re proposing here. We’re just starting with, let’s define the 23 functions.

Kip Boyle:

Okay.

Wes Shriner:

Let’s become familiar with those functions. And, and of course, it’s not going to help you if you show up and say, “Well, Wes said, this is what your job is.”

Kip Boyle:

Or Wes said, “You should actually have a Service Catalog printed that I can flip through.”

Wes Shriner:

That’s not going to help me. That’s not going to help anyone. You do approach and say, “Hey, so what is it you do?” Use this as a reference in your head to help you understand when they use key words that you recognize, you can associate them with this Service Catalog and understand that’s where, “Okay, I see where they are on the map. I understand now.”

Kip Boyle:

Right. Right. Right. And every time I look at this slide, I’m like, “Okay, so I’m at the mall. And I want to find the nearest Starbucks, where is it?” And the people that Starbucks, they never look at the map. Right? They just know what they do, so I don’t even talk to them about the map. I just show up and order.

Wes Shriner:

Well, I will tell you that one of the life skills of working as a professional in an organization is to understand your relationship to the customer. What is it I do? And how do I help the customer’s experience be better? How do I help this company make money? And if I can understand my relationship to the customer and to how the company makes money, then I am going to be much more successful in my career, right?

Kip Boyle:

For sure.

Wes Shriner:

And so this Service Catalog is part of understanding that, and I want to call out. Service Catalogs come from ITIL, the IT infrastructure library. I-T-I-L, and that is a jargon that I’d like you to go look up as well, because that’s a common IT operations framework for how do technology organizations function?

Kip Boyle:

Definitely.

Wes Shriner:

Service Catalog is just one of the mechanisms the ITIL offer. And I recommend it as one of the things to start with when reading up on ITIL. I do want to call out a kudos to Aaron Willer. He and I put this together six or seven years ago. And so thank you, Aaron, for all your help in building this and love to have you on the show one day.

Kip Boyle:

Yeah. Let’s invite him.

Wes Shriner:

We will. We’ll get a chance to. So, part of strong security leadership is defining for your organization what you’re doing and what delivery is expected. Right? If we don’t define for our folks what they’re doing and what’s expected, then they’re not going to understand and they’re just going to kind of run towards the next thing that looks like a fire, right? We can efficiently deliver key services for our business partners when we assign roles and responsibilities and hold people accountable, delivering on specific deliverables, such that our organization isn’t one sided.

Okay, so we’ve introduced the Service Catalog. Again, I haven’t read through them. I’m going to do that on the next slide. We’re going to go one more slide and then it should be fun.

Kip Boyle:

Great.

Wes Shriner:

Let’s see where we go with this.

Kip Boyle:

I really like this, Wes, because what you said a moment ago, you are helping the audience get into the head of the hiring manager, right? What is the hiring manager thinking about? And how are they using that to evaluate job candidates, right? Is somebody going to help you serve your internal customers or not? I mean, that’s really important. So not only are we giving you a tour of the security organization, but we’re also cluing the audience in to how hiring managers think.

Wes Shriner:

Indeed. And I want to thank you for sticking with me all the way to this slide. This one is it. This is our money slide for today. I’m really excited about this slide. This is a first time release to the world. So da, da, da, da, da, da, da. It’s here.

Kip Boyle:

And thank you for releasing it on Your Cyber Path. Let’s do it.

Wes Shriner:

There you go. This will become our anchor diagram for the entire course, for everything that we cover here. We’ll be referring to it every week as we build on the concepts of interdependent security organizations. We built this from a single Cybersecurity organization to defining 28 individual teams, 23 Service Catalog items. Let’s dive in and take a look.

Kip Boyle:

Great.

Wes Shriner:

If we start at the bottom, we’ve got an operation, Security Operations. We’ve already heard about that as an organization. We know that they do the security operations center, the cert and the forensics functions. Inside those disciplines, we have Security Inquiries, inquiries might be, and I’m sorry, the number 1 is Inquiries. We’re going to manage the security email inbox. It’s probably not a dedicated staff team to manage that inbox. It’s sort of a thing the SOC just does along with everything else that they do. Mm. Right.

Kip Boyle:

So it’s kind of the front desk for the whole thing?

Wes Shriner:

Very much so.

Kip Boyle:

Okay.

Wes Shriner:

And then they’re also going to do number 2, monitor security events. And that’s a 24-7 team identifying and investigating events. I want to be very clear an event is not an incident until it grows up. Events are things that happen in our environment and they get alerted or they don’t get alerted for that matter. But when we have an event, we get to investigate it and determine if there’s an incident or not. And so that’s how we’re going to follow this through. Events are evaluated when we monitor security events. This is a great place in your career to get started. This is where I would guess half of security starts is in the security operations center as their first security job.

Kip Boyle:

All right.

Wes Shriner: 

Would you agree with that Kip? Would you add anything to that?

Kip Boyle: 

I think that’s correct. And at the same time, I’ll also say that you can think of this as paying some dues because sometimes this work can be a bit of a grind. So there you go.

Wes Shriner:

It also puts you in a spot where you learn everything about the enterprise. You learn how everything turns in and out, you know what events are triggered, and which ones matter and which ones don’t.

Kip Boyle: 

Oh my gosh. It’s a unique perspective.

Wes Shriner:

It’s powerful. It positions you well for a strong career in security. And it is very common. You grow from this in to the CIRT. The Cyber Incident Response Team, the C-I-R-T or CIRT. CIRT has two Service Catalog items. Incident Response is number 3 and Security Countermeasures is number 4. A verified event becomes an incident and the incident is handled by your incident response team. I’m going to leave that one here for now. They’re probably going to run a minor attack framework. We can go into more detail on that when we go into that service itself.

Kip Boyle: 

Right. And we’ll do that in a subsequent episode, right? A future episode.

Wes Shriner: 

Indeed. That’s promised and exciting. It’s on the horizon. It’s coming.

Kip Boyle: 

And it gives you, everybody, a reason to come back.

Wes Shriner: 

Indeed. The fourth one is Security Countermeasures, and that’s hard, right? It’s hard to attribute accountability to an attacker. Oftentimes there’s a pawn in between the attacker and your organization. that takes the attribution.

Kip Boyle: 

Definitely.

Wes Shriner:

And that becomes very difficult for… There are very few small or medium sized organizations that do much in security countermeasures. You’ve got to be a large organization to do threat attribution and countermeasures.

Kip Boyle: 

Yep, it’s expensive. It takes a lot of time.

Wes Shriner: 

It does. We are starting to see companies offer services where you can create a honey bucket and drop them into a black hole so that if an attacker is coming in, it just drops into the black hole. They don’t even know they’re in the black hole and they just wander around aimlessly. And it’s fun to watch them. But even that takes some organizational fortitude to put that in place.

Kip Boyle: 

Definitely agree.

Wes Shriner:

All right. So the third function out of Security Operations is your forensics function. This is your digital forensics. It’s number 5. This is the team that owns their toolkit and the authority to go anywhere and see anything as long as they have proper approvals, right? This team is all about accountability, chain of custody, and ready for deposition.

Kip Boyle: 

And understanding the deep dark details behind how things actually work, like browser history.

Wes Shriner:

Indeed.

Kip Boyle: 

And other things, right? Like how files are created and deleted on a spinning disc or on an SSD. You know, all this stuff is very much behind the scenes for most people, but there is a ton of data down there if you know how to decode it.

Wes Shriner: 

There is. All right, so now we’re going into security tools. And this is an interesting area. It seems like a really small area until you open it up and you go, “Wow, this there’s a whole world inside here.” So inside the Operate Security tools, you’ve got internal security team tools. That would be tools the security team uses to do their business. That might be the GRC tool. It might be vulnerability scanner. It might be the forensics tool kit. It might be SOC or SIM. It might be your CIRT tools, your threat Intel feeds. It could be your team analytics functions.

Kip Boyle: 

How about a ticketing system?

Wes Shriner: 

Yep.

Kip Boyle: 

Or service request.

Wes Shriner: 

Yep. You got to know what comes and goes. Then it’s also going to maintain your company facing security tools like your antivirus or your Absec scanners, right? They’re also going to own your product security tools if you’re offering a services to your customer. Then you may be monitoring the services and protecting your services in a secure way as well. You could have a parallel organization with incident response for both internal and then external customers.

Kip Boyle: 

Right. So, in the last episode you gave Xbox as an example, right?

Wes Shriner:

That’s true.

Kip Boyle: 

Of product security, right? That means that people are logging into their Xbox account, so that’s an entire infrastructure of identity and access management that needs to be running at all times. And then diagnosed and fixed when necessary.

Wes Shriner:

Yeah. Yeah. This is also the team that owns the relationships with company security tools that aren’t owned by security. So if you’ve got a Splunk, Splunk very much has a security component to it. And it’s very much a part of what we do for logging and alerting, the exchange infrastructure, the active directory, maybe your privileged user management, like CyberArk or something like that. This team owns the relationship with all of those security tools around the organization. Either they own those tools or they own the relationship with them. I want to call out that this team is a great place to transfer in from other parts of IT.

Kip Boyle: 

Ah, okay, so if you’re a database admin, systems administrator, that sort of thing, right?

Wes Shriner: 

It’s still data base administration. It’s still systems administration, and now you’re a lot closer to being inside security because you’re operating security tools.

Kip Boyle: 

That’s great. So there’s a side door that you may not realize, people who are watching and listening right now.

Wes Shriner: 

And then the next part of the security tools is really your continuous automation functions. We’ve got to get better. We’ve got to purge our technical debt and the best way to do that is a continuous automation function. That’s going to be in your security tools team. It’s primarily associated with these security tools, but they can do it for any piece, right? This is internal tools and development team.

Kip Boyle: 

All right.

Wes Shriner: 

All right. I want to look at that third discipline under Security Operations, lights on operations. I you’ll see me abbreviate quite a bit with LTLO or keep the lights on. This is very much the services that security runs, that if they don’t work, the company ain’t working, right? We would say at Nordstrom, “If you can’t sell shoes, it’s not going to help you.” How does this help you sell more shoes, right?

Or in this case, if these services are down, I can’t sell shoes and that’s a problem, right? So these are keep the lights on operations. Some of the security functions, if it’s not working, we can bypass it. It’ll fail open. We can keep working. Some of these security functions when they fail closed, we have a very serious business problem. And so understanding those… Identity and access management is the first one, right? This could live in the security tools. It could live in the keep the lights on. I actually prefer that one here because without it, the company can’t go to work. This is also a great place for a professional to get started in their career. This is IT operations, and it’s very much understanding how does identity and access management work. It’s a powerful place to be. Yeah.

Kip Boyle: 

And that’s a really important service anywhere. You’ve got to be able to identify people before you give them access to stuff. So, super important to understand how that works.

Wes Shriner:

And you’re going to be doing APIs. You’re going to be doing open SAML and SAML communications. You’re going to be integrating with every application in your company if you’re building a single signon tool. All right. The second team in there is your network and firewall management team. Now that team may or may not actually be inside security. If they are inside security, they would absolutely be in this area of security. There may be a network engineering team separate from security. And that’s great. If firewalls live there, the more, the better, right?

Kip Boyle: 

Yeah, and I’ve had that situation where I inherited a security program where the firewall administrators were members of the security team. I ultimately ended up packaging that up and shipping it off to the IT department and having the network administrators actually take that over. And my business case for that was I couldn’t add more people to my team, but there were some high value activities that I wanted to be able to do. In other words, there were parts of my Service Catalog that I wasn’t feeling like I was putting enough time and energy into. And so I looked around and I said, “Well, what services can I minimize or just hand off to somebody else so that I can invest more energy into these other areas?” And so this ended up being the answer for me.

Wes Shriner: 

It sounds like that Service Catalog could also be used as an audit criteria or a self scorecard to be able to say, “How am I doing against the common services that I would expect to be doing in a security organization? And if I want to invest more in this area, how am I going to save some money over here?” And it sounds like that’s a great plan.

Kip Boyle:

Yeah. And so that’s another example of how hiring managers think, right? I mean, these are problems that we don’t typically share with the team until we’ve made some kind of a decision that, “Hey, I think this is the direction we’re going to go in. Would you give me your feedback?” But there’s so much that a hiring manager is doing that they’re not necessarily sharing with team members because there just isn’t a need to know, and I’ve actually found that if I overshare it can confuse people,.

Wes Shriner:

Confuse people, make them insecure, or potentially feel like maybe they don’t have as much of a future, as strong a future as they’d hope to have here. Then they might leave voluntarily before anything negative happens. And that’s kind of lousy too, right?

Kip Boyle: 

Or maybe nothing negative is going to happen. And I’m just exploring a possibility, right?

Wes Shriner: 

Exactly.

Kip Boyle: 

It just kind of makes people feel uncomfortable, so got to watch out for that.

Wes Shriner: 

All right. So now we’re looking at Service Catalog, item 8, Operations by Security. And that bridges both the network and firewall management and shared security services. That shared security services could be any function that lands in a shared security services space, right? So maybe it’s your VPN. Maybe it’s the firewalls. Maybe it’s encryption as a service. Actually, any as a service. Could be gear cloud services. It could be tokenization calls.

Kip Boyle: 

Okay. And when you say “shared”, who is sharing these things?

Wes Shriner: 

These are all shared internal IT services that are shared by multiple teams. If I have a centralized API infrastructure where instead of creating point to point communications on every API, I run everything through a centralized, maybe Apigee solution, right? That may be owned by my development team, or it may be owned by my security team. If the security team owns the Agpigee interface, then every plugin that goes into that Apigee has security criteria that we want to see met in order to be a citizen in our Apigee community.

Kip Boyle: 

That’s a great example. Thank you.

Wes Shriner: 

Now let’s turn that on its head. If Apigee lives in your technology teams, in your IT team, that’s just fine as long as your security team is driving requirements into your Apigee to understand, “This is the policy for how it should be run. These are the expectations for how you should secure the application. And then this is the expectations for how, when a data subscriber or a data provider wants to enlist, this is the expectation. I want a mutually authenticated, encrypted communication channel, etc.” Sorry, I’m-

Kip Boyle: 

Does that bring us to the end of the security organization or security operations?

Wes Shriner: 

That takes us to the end of security operations. Sorry, I got lost there in the APIs. That was kind of fun.

Kip Boyle: 

Ah, you’re the first right? You’re the first to get lost in API.

Wes Shriner:

I can’t be the first.

Kip Boyle: 

Just call the string out.

Wes Shriner:

So I’m going to go to the top right of the architecture diagram. We’re going to see Security Engineering, Architecture, and Test. I want to call out the top two and I’m going to do them by contrasting the two. The first one is security strategy and architecture and the second one is solution engineering and architecture. They sound very similar. Think of strategy and architecture as your five year roadmap. This is your number 10, Security Architecture Function, but this is your roadmap and your reference architecture for where are we going as a company, long term, in our technology roadmap and in our security roadmap and how do they work together?

In contrast, number 11 is your IT Project Support. This is your solution engineering and architecture team, and it’s very much focused on solution engineering and solution architecture. This is every solution we build keeps the promises we’ve made to protect data for our customers.

Kip Boyle:

Okay. So would an example here be like a self-service customer portal or something like that?

Wes Shriner: 

Exactly. It could be a self-service customer portal. Could be any widget our company creates, whether it’s customer facing or internal. If it’s handling customer data, we made promises to our customers, our stakeholders, and our shareholders that we will protect your data to a reasonable level in these ways. And we made those statements and they invested in us, whether they invested their data or their time or their money or their commitment or their shares. So, in whatever way they’re invested in us, we need to keep those promises. And this is about keeping that promise at the design and architecture level of every solution the company creates. Right?

Kip Boyle: 

Got it.

Wes Shriner: 

All right. So let’s keep moving because I don’t want to get… Oh, let’s call out. You can do a lot of very senior roles in that team, right? This is a great spot for the senior, senior technologist who has been writing code for 20 years and has been telling the people around them that it’s time to write your code better. It’s time to administrate your database better. And maybe they’re at a spot where they could do that specifically for security and be very effective in a role.

Kip Boyle: 

Yeah. We need a lot of gray beards in there. Right?

Wes Shriner: 

It’s a great place for it. I’ve seen some gals who are really effective in those roles as well.

Kip Boyle:

Oh, definitely.

Wes Shriner: 

Very mentoring, very coaching, very… Because if we just say “policy says” in this role, it’s not going to last very long. You’ve got to build the business case for why the people who built it, or are planning to build it, need to modify their design. All right. So next step down. We’re looking at number 12, Vulnerability Management with the team of the same name. This is your hygiene team. This is scanning. This is patching. This is checking your assets to make sure that (a), you know which ones are your assets, and then (b) how healthy are they? If we’re running windows 95, we’ve got a problem. And your vulnerability management team should be able identify what servers are running down rev applications and operating systems.

Kip Boyle: 

Right. Right. And then they’re also going to be the ones making mitigation recommendations, aren’t they?

Wes Shriner:

Oftentimes there will be mitigation recommendations. This is also the team when your boss gets a phone call from their friend and says, “Hey, do you know, are you subject to POODLE? Is POODLE going to get you guys?” This is the team that can go scan your environment and look for SSL versus TLS to determine, “Well, we’re internally vulnerable, but not externally vulnerable. We’ve already gone to TLS 1.2 externally.

Kip Boyle: 

This is so funny. I just have to make a comment right now how interesting it is that some of these really big vulnerabilities actually have their own branding. They’ve become like celebrity vulnerabilities. Isn’t that crazy?

Wes Shriner: 

We all knew what I said when I said it. And if you haven’t Googled the POODLE vulnerability and have some fun and then go look at Heartbleed.

Kip Boyle:

Yeah. Heartbleed. Yeah.

Wes Shriner:

And then step in the time machine and go look up Melissa and SQL Slammer just for fun.

Kip Boyle: 

Oh geez. A blast from the past. Keep going.

Wes Shriner: 

All right. The next team is Application Security and your next function is really number 13 security testing. Security testing bridges for teams, really application security, the security functional testing team, bug bounty, and also your penetration testing, but understand I’ve called that application security specific because this is a growth area. This is a spot where we’re investing as a security organization in 2020. It’s very much an area where we’re getting better fast.

Kip Boyle: 

This is because the number of applications is just proliferating.

Wes Shriner: 

This is the team that owns the security decisions through the delivery pipeline. They own the code repositories, internal and third party. They own the shared libraries and coding best practices. And, I’m sorry, when I say own, I mean they own the security story for each of those activities. Those are rarely owned inside the security organization.

Kip Boyle: 

And, you know, think this is the future too, because applications are becoming serverless.

Wes Shriner:

Very much so.

Kip Boyle: 

Yeah.

Wes Shriner: 

Very much so. Lambda is on the rise in every direction. Security functional testing really validates the security requirements that we saw in IT project support, right? If your solution architect gave you requirements, your security functional testing team should be testing against those requirements to validate that they’ve been met or not met on go live. Once it’s gone live, your bug bounty team, this is part of your testing organization. Really your bug bounty team, it’s usually one or two individuals. They’ve got a third party contract that is receiving external claims-

Kip Boyle:

Reports for viruses.

Wes Shriner:

from vulnerability researchers saying, “Hey, I found a thing in your code.” So then they use the vulnerability scanning tools to go determine if that thing in my code really exists. Oftentimes there’s a deep investigation in that. And then sometimes incident response is pulled in, especially if it’s been exploited already. Then we come back to, okay, well, we go pay the virus researcher, the vulnerability researcher who found it for us, and we go take on the next one, right? That’s that’s our bug bounty team. And penetration testing, now this is the sexy area. This is the one that everybody knows of first. And I thank you for following me all the way to number 13 to get here. Because, oh my goodness, did you hear how much was available to you before we even got to 13?

Kip Boyle: 

Yeah. And 13’s like the thing that everybody knows about. “I want to be a network penetration tester, red team, blah, blah, blah,” and nothing wrong with that. Nothing wrong with that, but there’s so much more.

Wes Shriner:

Oh man, eat the whole hamburger. There’s a lot of good food there. All right. We’re going to turn the corner now. Penetration testing is really turning that corner from prepare and defend and moving more into actively looking for exploits. And that’s what threat hunting becomes. Threat hunting is Pen testing on steroids. It’s not in place everywhere. This is not something that every security organization is doing yet. Number 14, threat hunting, it blends with a threat intel team and is very much actively internal testing. It’s been called Pen testing with less paperwork.

Kip Boyle: 

That’s great. You know, threat hunting is absolutely the future, I think, because it’s just so relatively easy today, compared in the past, for a cyber attacker to gain a foothold in your network and then to do it silently and then to sit and watch and observe and to do that silently. So if you’re not looking for them, you’re not going to see them. And we just know that this has been happening a lot. Equifax, right? I read every report I could get my hands on that purported to describe how the Equifax hack went down and a common theme in there was that the attackers gained a foothold. They did it silently, and they maintained that foothold and conducted extensive internal reconnaissance for weeks.

Wes Shriner:

Yeah. And so the phrase assumption of breach is one of the critical phrases in a security organization. We have to assume that our organization has been breached, whether or not we know about it. And that’s why your threat hunting steps up and says, “Let’s see if we can solve that.” Threat hunting is paired with number 15, threat intelligence. They have very similar names, but they have very different functions, right? If threat hunting is internal evaluation of my network and my environment, threat intelligence is looking outside. It’s monitoring the dark web for mentions of my company name, for my executive names, or industry players. It’s going to monitor active weaponized attacks. And then I’m going to provide daily briefs on what I’m seeing on the dark webs to my leadership and to my peers so that we can better protect and defend our organization.

Kip Boyle: 

You know, a lot of organizations are so busy looking at their own stuff that they really just miss what’s going on outside their four walls, and the world can just pass them by. I’ve seen this happen and I’ve helped different companies figure out what to do about it because they didn’t have a threat intel capability and they just fell behind and they had to figure out how to catch up.

Wes Shriner: 

And the threat intelligence feeds are getting smarter and smarter so that we can really rely on those in some cases to help us. If we don’t have the manpower to build a big organization, let’s use the feeds available to us to build something. So that takes us the end of engineering, architecture, and test. We’re going to jump to the top left and governance risk and compliance.

Kip Boyle: 

Okay. Two security orgs down. Two to go.

Wes Shriner: 

Indeed, indeed. So we’re going to start with security governance because everybody loves that word governance. It means so many things to so many people. And I would ask you to stay with me because there’s a lot of really interesting jobs in that governance, risk, and compliance space and a lot of places where you can get started as a team member. Sometimes get started in a non-technical, but still security related role.

Kip Boyle: 

Definitely.

Wes Shriner: 

Or maybe technical in different ways. Instead of being a software developer technical, maybe it’s more of a compliance specialist or a technical analyst. And so let’s take a look. Number 20 is our governance and PMO, right? This is the group that does our annual planning. They figure out what our organizational priorities are. They set the budget, they set the goals, prioritize projects and track against those projects as they work to deliver them. PMO means project management office, and this is where your project managers start out. So you may find there’s a small group of project managers, and that would be a great place for a college graduate to get started.

Kip Boyle: 

Number 21 is your policies and standards. That’s your policy governance. Usually there is one policy administrator for the organization. If there’s an open position for policy administrator, that’s very much an entry level role and can also be done by a very senior person. Whatever that policy manager administrator brings to the role is going to be a benefit to the organization. And so sometimes that’s lower level. Sometimes that’s a higher level individual. Both bring a lot of value.

Yeah. And I want to take a moment to say that there’s opportunities for people who are coming in. Like if you’re good at project management in the construction industry, you have a ton of transferable skills here. Same with policy, right? If you have experience administering policies in other contexts, human resources, or what have you, lots of transferable skills.

Wes Shriner: 

A lot of technical writing skills that go into policy, right? My policy administrator does not, and almost never, actually defines or dictates what the policy should be. They’re all about the process of how do I receive the input, evaluate it against the committee that owns it. Once everybody says, yes, then move it forward for signatures. So it’s very much an administrator type role. That third one I’m going to call it, in governance, is number 22, management reporting. This is the governance team that reports to your board of directors. This is the governance team that brings your cyber risk to your enterprise risk. This is the team that reports to governance councils for privacy and security. They also own the analytics platform. If security analytics is a thing and, and I’m going to say, that’s kind of a new thing, it’s pretty powerful to have a security analytics function, and it would live with this reporting team

Kip Boyle: 

And think about how crucial this is that you have really good data quality and also that you are presenting the data in a way that sets up the decision makers for success. I’ve seen this done very poorly and it left the decision makers confused about what they really should be paying attention to. And I’ve seen this done really well, and such a difference because then the decision makers are empowered and they’re allocating resources in a much more effective way. And they generally spend less money too, because the money that they are spending is actually producing better results and more results. So yeah, this is a crucial function.

Wes Shriner:

I’m going to ahead and spin off on that for just a second as well, and say a well defined problem leads to a very obvious solution in most cases. And defining a problem well is going to come with data, right? And that data’s going to come from your management reporting and security analytics. So, very much, a well defined problem, easy solutions. If you’ve got easy solutions, you take them up to that PMO team. You line them up for next year’s budget. And then you use the PMs to deliver against those projects. So that management reporting really is a critical, critical function for security. Next one down is cyber risk management. There are two functions inside here. 23 is cyber risk management. 24 is third party and vendor risk for your cyber risk management. This is the team that owns your risk register. They own, or sometimes it’s called a risk reserve or risk register. Have you heard other names as well?

Kip Boyle:

Risk register is the common one that I hear, and what’s a risk register? Well, it’s just a list of all the risks that you know about and it’s quantified and described and hopefully prioritized. That’s crucial.

Wes Shriner: 

It better be prioritized and it needs to be written in business language. Don’t write it in tech speak and tech jargon because no one will understand why that risk matters.

Kip Boyle:

Nope.

Wes Shriner: 

Got to be written in business language.

Kip Boyle: 

And that’s a very common oversight/mistake. And, again, it kind of goes to this idea that decision makers need to be set up for success, and a bunch of tech jargon’s typically not going to do you that.

Wes Shriner: But you need to understand the technology in order to be able to write down the business problems that are created in a cyber risk space. So I would encourage you. This is a great place for a new person to get started because they get a chance to consume the technical, apply the business, prioritize and stack rank what scares us the most and why, because this is the team that defines what keeps us up at night.

Kip Boyle: 

Super insightful.

Wes Shriner: 

So this is also the team that interfaces with enterprise risks. So cyber risk makes their list and then cyber risk gives it to the enterprise risk team, which is a larger enterprise organization. If you’ve got the big company, the fortune 100 type thing.

Kip Boyle: 

Yeah. And they’re looking at all kind of things, like currency fluctuations. I mean, it’s amazing the different types of enterprise risks that they will track and cyber risk is just one.

Wes Shriner: 

1 of 15. Yeah. They’ve got a lot going on. All right. So third party risk is another interesting place and this is a, an organization, an example of one that just opened up in the last couple of years. There was not third party risk five years ago. I’m sorry. There were third party risks. We did not have them calculated or quantified or managed effectively-

Kip Boyle: 

That’s right.

Wes Shriner: 

until target happened. Right?

Kip Boyle:

Right.

Wes Shriner: 

Target. And the HVAC system turned over a new leaf and we invented third party and vendor risk management for security organizations. So let’s think about what that team is for just a minute. Customer has given me their data. I am using their data. I want to integrate their data with something else so I ask a third party to take my customer data and use it over here for the customer’s benefit and then give it back to me. In doing so that third party is now accountable for my promises that I’ve made to my customer. And this is just evaluating that third party to make sure that-

Kip Boyle:

That they’re trustworthy.

Wes Shriner:

their policies and standards are consistent with my policies and standards and they’re going to take care of my customer the same way I would.

Kip Boyle: 

Yeah. So let me give you a quick example. It could be like I’m a bank or a credit union, and I need to mail statements every month to my account holders. Well, I mean, these days banks don’t print their own statements. They outsource that. And so that means there’s a printing press somewhere or a big bank of laser printers or what have you, and the data has to be printed out on paper, which means it’s got to be shared. And I’m sorry, but even the best printing organizations in the world don’t consider themselves to be banks. But they’ve got to protect that data as a bank would. And so, hopefully this starts to put just a little bit of color on the fact that it’s great to use a third party vendor that has a specialty in something that would take you a lot of time and energy to develop when what you really want to do is run a bank or a credit union. You don’t want to be a printing expert, but it’s how that data flows back and forth that can create a lot of problems in terms of data breach.

Wes Shriner:

Right. Thank you. And now we’re going to jump to number 25, compliance. Compliance is a tiny little piece of this diagram, but I’m going to tell you it can grow to be pretty big, especially if you ignore it.

Kip Boyle: 

Yeah.

Wes Shriner: 

Compliance is regulatory compliance. It’s government driven. It could also be industry driven. It can come from any different sources, but once those compliance requirements are in place, we’ve got to figure out as an enterprise organization, how we’re going to respond to those.

Kip Boyle: 

It could be internal compliance too, right? Because you have your own internal policies and those policies exist for a reason. People need to follow them.

Wes Shriner: 

Well said. Well said. So what are some examples of compliance that we would expect to see if we’re in a common marketplace today?

Kip Boyle: 

Oh gosh, there could be… You know, if you’re taking credit cards, then the credit card payment industry has self-regulated.

Wes Shriner: 

PCI is a big deal.

Kip Boyle: 

PCI DSS, right? So that’s something, and that’s a big deal because if you don’t adhere to it, then your right to process credit cards and to receive payments for services and products can be revoked. Yikes.

Wes Shriner:

Revoked, or the cost of doing business goes up if you start having findings. If you start having errors and finding, they just say, “Well, instead of 0.25 cents per transaction, we’re going to charge you 3 pennies per transaction.” Which is a significant business hit. And it’s amazing how much more your business wants to comply and help you comply when the cost goes up.

Kip Boyle: 

Yeah. But there’s a other slippery compliance things too that don’t immediately result in such obvious detriments. If you are a healthcare entity, you’re a medical center and you are outsourcing laboratory diagnosis. So, testing of blood and whatever tissues and that sort of thing. Then you are going to have to have an agreement with those organizations, a business associate agreement, to make sure that healthcare information is protected. Sometimes you might actually share that information with an actuary, an actuarial firm, because you’re trying to figure out what your costs are going to be next year. Or if you’re an insurance company, how much should you charge for insurance premiums in the next year. So you’ve got to share that data and you need an agreement that’s going to decrease the risk that this partner is going to fumble the ball. But the thing about it is if you don’t put an agreement in place, it won’t necessarily come back and bite you in such a direct way as a credit card increase of processing fees, but it could bring you to a massive data breach, which could be very unfortunate.

Wes Shriner: 

What I heard you talking about a little bit was the HIPAA, right? The health regulations, H-I-P-A-A.

Kip Boyle: 

That’s right.

Wes Shriner: 

I’m going to drop a couple other acronyms on you, just so I can sound smart along the way. But we’ve got SOX, which is our Sarbanes-Oxley law that came out in 2002 and it’s very much about user permissioning and making sure that the person who writes the check and the person who signs the check are two different people. If you print it, you can’t sign it kind of thing. And that’s true. That’s a very simple example. But Sarbanes-Oxley is about segregation of duties and least privilege access.

Kip Boyle: 

And if you’re a publicly traded company, then that is on your compliance landscape.

Wes Shriner: 

It is. Very much so for every material application.

Kip Boyle: 

And what about privacy? Let’s not forget GDPR, CCPA, right? What kind of data can we collect and then how do we have to protect it? And how do we have to delete it if a proper delete request shows up? So, tada.

Wes Shriner: 

GDPR is for European citizens. CCPA is for California citizens. I really wish we had some privacy laws here in Washington state. One day I hope we will.

Kip Boyle:

Well, you know what? It turns out, just a quick aside, that organizations that operate nationally in the United States are typically standardizing their privacy practices to the California requirements. So it’s actually starting to have an effect on the broader national landscape.

Wes Shriner: 

Another one might be G L V a, right? The Graham Leach Bliley act for banking. One thing I saw in telecom was CP&I. That’s your call data records and making sure that nobody can download the last 10 phone calls that, what was her name, I don’t know. Some folks downloaded a bunch of call records for famous actresses and thought that was pretty cool.

Kip Boyle: 

Yeah. And, oh gosh, it just goes on and on. So there could be criminal justice information. If you’re doing business with anybody in the criminal justice system.

Wes Shriner: 

Education. Education information, and what you share with your professors. And maybe the last one I want to call out is child protection. Anybody under the age of 13. So there’s a lot-

Kip Boyle: 

There’s a lot.

Wes Shriner:

of compliance out there.

Kip Boyle: 

There’s a lot. This box is too small. Let’s make it bigger.

Wes Shriner: 

Make it bigger. Put stars next to it. Make it shiny.

Kip Boyle: 

Yep. The color red. More red.

Wes Shriner: 

Make it pretty. All right. And the last one is actually my favorite. It’s security awareness and training. Number 26, training and awareness.

Kip Boyle: 

Oh, not the college entrance exam. That’s a release.

Wes Shriner: 

No, not SATs like your college entrance exam. It’s security awareness and training. This is your October cybersecurity awareness month. This is your training arm in the organization, and this is a great place to start your career. This is about influencing and about changing the behavior of an organization from what was, to what is healthy. The threats that happened in the marketplace 20 years ago when I got started are not the threats of today. And the behavior that I had 20 years ago is no longer acceptable in today’s marketplace.

Kip Boyle: 

That’s right. Yeah. Phishing attacks, password management. It just goes on and on.

Wes Shriner: 

We’ll talk about seat belts at some point later. But the understanding that when we grew up, no one was required to wear a seat belt, but somehow in our economy, in our country, in our world, we all learned that seat belts are valuable and part of daily life and click it or ticket is part of everybody’s language now. How did that happen? And how do we make that happen in the security space is what security awareness and training is about.

Kip Boyle: 

Yeah. And a closely related example, which I think is really good, is driving under the influence of drugs or alcohol. I mean, when I grew up, it was like, “Oh, there goes, Pete again. Home from the bar. Watch out for Pete. He swerves on the road.” I mean, it really wasn’t taken seriously.

Wes Shriner: 

And that was not good.

Kip Boyle:

No, it was terrible.

Wes Shriner:

We lost a lot of lives.

Kip Boyle: 

We did. But look where we’ve been able to get. It’s fantastic.

Wes Shriner: 

We have really turned that one around as a country, as well, as a people. All right. So that takes us to the end of governance risk and compliance. Three down. One to go,. Yes, indeed. Product security is our last one. There are two arms to this. Number 31 is product security. Number 32 is your product services security. Mm. I want to call that out as two separate things. We did a little bit on that earlier in our last episode. Product security number 31 is about device security and device privacy. It’s about product third party risk.

It’s about product compliance, product feature grooming. It’s really a parallel of a lot of the services we’ve seen inside our enterprise applied to the product or device that we’re delivering to our customer. Product design engineering and test, architecture, those are all pieces to that product security. Now then the second one, 32, is product services, security. And that’s really, it’s all the same things for the service end of your product. So we talked about Xbox previously and Xbox is the product. And then the Xbox online is your product services, right? Focus on web security, network security, customer identity.

Kip Boyle: 

Yep. And we’re seeing more and more and more of this as time rolls on, as more products become internet connected, internet capable, and that we’re delivering services to those internet connected products. You know, hey, when I’m running out of milk, I want my refrigerator to tell me.

Wes Shriner: 

And your IOT device is the product security and the connection between that IOT device and your email telling you that it’s time to buy milk is the service.

Kip Boyle:

Right, and it’s got to be secure.

Wes Shriner: 

So folks, I want to thank you for joining us on this tour of the common security team structure. This is not how every team is built. This is how some teams are built. There’s sometimes a little more, sometimes a little bit less, but in every case, it is a good example of how we can get started. Then we decide in and decide out what we do from here. We’re going to use this diagram as a platform for everything else we do in this podcast. It’s going to be a roadmap for where we go from here. We’re going to revisit it very often and drill deeper into a lot of these organizations, disciplines, services, and some of the teams too.

Kip Boyle: 

Yeah. And some of the jobs that might be available to you as somebody who is new, trying to cross into cybersecurity and then jobs that you can grow into. So all of that is coming, coming ahead in future episodes.

Wes Shriner: 

It is. So the key takeaways, cybersecurity is complex.

Kip Boyle: 

That should be obvious.

Wes Shriner: 

But it’s understandable. It also is understandable and navigating it, understanding it, helps us find our dream jobs.

Kip Boyle: 

That’s right. You want to get a nice fit, right? Between who are you? What kind of work do you like to do? What are your strengths? You want a job that’s going to play to your strengths. You’re going to want a job that fits the way you like to work. Do you like high energy environments? Do you like low energy environments? You’re going to find all this stuff at different levels of intensity throughout the organization. So, stick with us and we’ll help you understand all of it.

Wes Shriner: 

Next week, we’re going to cover a high level of security, budget, staffing, and organizational models. I realize that’s not directly related with what job am I going to get? But if you look at the budgets and you look at the staffing, you can see what organizations have a lot of heads that you might be interested in pursuing.

Kip Boyle: 

Yeah. That’s right.

Wes Shriner: 

And after that-

Kip Boyle: 

You need to know where the opportunities are. If there’s a single job position in an entire organization and you want it, and that person isn’t leaving anytime soon you need look for more opportunities.

Wes Shriner: 

What else can we do?

Kip Boyle: 

We’re going to give you some insights on that.

Wes Shriner: 

Very much. This was a lot of fun, kip. Thank you for doing this together. I’ve really enjoyed introducing the security organization. I look forward to where we go from here.

Kip Boyle: 

Oh yeah. And listen, ladies and gentlemen, if you are liking what you see, if you want more of it, if you want us to answer different questions about this material, then let us know, right? Send us a note. You can reach me at kipatyourcyberpath.com. I read everything that people send into that address. I’m not always able to reply to everything, but I do read everything and we want to hear from you. And then a beyond that, if you generally like what we’re doing with this podcast, then I want to let you know about a free guide that’s available to you and it’s called Play To Win, Getting Your Dream Cybersecurity Job. And if you’ve ever played Capture the Flag, whether in the woods at night like I did when I was a kid or the electronic equivalent these days, think about that approach, right?

You have an objective. You want to capture that flag and you can actually take that approach and successfully apply it to competing and winning in your hunt for the great cybersecurity dream job that you’re thinking about. It’s a really helpful visual guide. It’s about 20 pages. It has screenshots, specific instructions in there that you can follow, and it will teach you how to hunt for jobs and find hiring managers by using LinkedIn and Twitter. It’s really great. If you want to get it, go to yourcyberpath.com/pdf. You can put your email address in there and download it right away. Check it out. Let us know what you think of it.

That does it for today. So until we see you again, remember that you’re just one path away from your dream cybersecurity job. Thanks for being here.

Wes Shriner:

See you.

Headshot of Kip BoyleYOUR HOST:

Kip Boyle
Cyber Risk Opportunities

Kip Boyle serves as virtual chief information security officer for many customers, including a professional sports team and fast-growing FinTech and AdTech companies. Over the years, Kip has built teams by interviewing hundreds of cybersecurity professionals. And now, he’s sharing his insider’s perspective with you!

Headshot of Jason DionYOUR CO-HOST:

Jason Dion
Dion Training Solutions

Jason Dion is the lead instructor at Dion Training Solutions. Jason has been the Director of a Network and Security Operations Center and an Information Systems Officer for large organizations around the globe. He is an experienced hiring manager in the government and defense sectors.

Wait,

before you go…

Don’t forget to sign up for our weekly Mentor Notes so you can break into the cybersecurity industry faster!