Chapter 2

Identify your customers

Abstract

When you are looking to build a security operations center you need to know who the customers are. The customers may be internal departments or external customers.

Keywords

customer performance HR legal audit internal external use case

Chapter contents

 Internal versus external customers 27

 Human resources 27

 Legal 28

 Audit 29

 Engineering/R&D 30

 IT 30

 External customers 31

 Customer objectives 32

 Service level agreements 32

 Build and document your use cases 36

 Use case: unauthorized modification of user accounts 38

 Stakeholders: compliance and audit departments 39

 Use case: disabled user account reactivated 39

 Stakeholders: HR and IT 39

 Use case: any IDS event that scores over a severity of 7 40

 Use case: AV failure 40

 Stakeholders: desktop support team, IT server management teams 41

 Use case: security device outage 41

 Stakeholders: security and IT 42

 Use case rule summary 42

 Use case: top vulnerabilities detected in the network 44

 Stakeholders: security, IT, audit, and management 44

 Use case reporting summary 45

 Expectations 46

If you are building a SOC you should already have some kind of idea of who your customers are or why you are doing this whole SOC thing in the first place. The SOC may have been kick started because of a recent event or as a precaution to a potential event that could bring great risk to an organization. The charter for a SOC may just be simply to ensure a repeat event does not happen or that your organization does not get into as big trouble as some other organizations in your industry. It could also be that your organization has a lot to protect and needs the right monitoring and safeguards put in place. For whatever the reasons are that you want to build a SOC, you will quickly find out that the initial reasons that you wanted to build it will be greatly increased as soon as you start to build it. The scope of your project to build a SOC could become very large; therefore, it is important that you identify all the potential customers for the SOC prior to or during the initial phases of building the SOC. Once you identify who the potential customers are for the SOC, you can then start to design services and objectives to meet the needs of those customers. The various types of customers you may have will help dictate the types of services you will provide, the service level agreements you will need to maintain, and the key success metrics or key performance indicators that you will need to provide on an ongoing basis. Once you have a good idea as to who your customers are, you need to sit down with each of them and discuss what their goals and objectives are so that you can build out use cases that document what the specifics are that you are going to be providing and the reasonable expectations for the outcomes of those use cases. In this chapter, we are going to explore the various types of customers that your SOC may be providing services for. We will also take a look at how different customers may have different objectives, but if you build efficient operations you will find easy ways to service almost any type of request. Documenting use cases for your customers will not only help your operations understand their performance requirements but will also help customers understand what they will be getting from you. We are also going to discuss several different types of use cases for the SOC to give you a broad-spectrum understanding and a basic list of what a SOC could do for the organization. No two SOCs are alike. Your customers may be very different from the customers of other SOCs. The objectives and tasks may be similar, but the processes, risk tolerances, and reporting requirements along with the culture inside your SOC would almost always be different from any other SOC. This does not mean that you cannot share ideas and learn from other SOCs, as each SOC should strive toward being better and better with every ticket for every incident they face. As we discussed prior, a SOC is typically built out of necessity. There is a very specific and direct need to build an operation center that is responsible for the management and monitoring of the security infrastructure. The SOC needs to ensure that alerts and events are addressed in a timely manner and that all incidents are handled appropriately and escalated effectively. Once we have a clear understanding of what the expectations are, we then need to address the customers' concerns and ensure that the tools and processes in the SOC are going to appropriately meet those expectations.

Internal versus external customers

A general understanding of who the customer is, is a vital step when looking to build a SOC for the first time. Initially you may think that the customer is just internal, that it is the IT department or the entire organization or company the SOC is working for. You may also think that if you are a Managed Security Service Provider (MSSP), it is easy to see who your customers are because they are whoever is paying you for your services. These would all be dangerous assumptions, and the SOC leadership needs to dig deeper and make sure that not only do they understand who the customer is but also that everyone working in the SOC understands. All too often working in a SOC I hear people complain about users who constantly get viruses or try to access blocked sites. The analysts get frustrated because the users never learn and just make more work for the analysts because all the tickets need to be addressed no matter how many times the user gets a virus or accesses something bad on the Internet. These types of events can happen often, but when you realize that it is the user in this case that you are working for then it should be easier to deal with. In other words, when a SOC analyst understands that their responsibility is to protect the users and ensure that they do not lose their identity or that malware does not access or transfer protected data off of a user's computer, then their attitude may change. In the above example it is the user the SOC is working for, but users can be a part of many different internal organizations and may have different needs other than just having someone make sure their endpoints are safe and clean of malware. A data breach is a good reason to set up a SOC but what data do you protect, where is the data to protect? Typically, organizations that have had an issue start off looking in one direction for their security requirements but soon realize that there are a ton more areas that need to be protected. From an organization's standpoint, a SOC is a great way to get experts focusing on a problem. From a security or SOC's perspective, there are many different things to focus on. Building an efficient Security Operations Center is a corner stone of execution to any organization's security program and is an essential element in achieving the overall organizational goals. Let us take a look at who the customers are and how the SOC can help each one. Keep in mind that the security infrastructure and tools may be the same but how the systems are configured, designed, licensed, or used may be different in different organizations.

Human resources

The human resources (HR) department is typically a very important customer of a SOC. The ethical behavior of the people inside an organization is a great concern to the HR department. For many years organizations have authored codes of conducts, ethical behavior policy, harassment policies, acceptable use policies, and more. But until recently an HR department was at the whim of the people in an organization to report issues or bubble up real problems to be addressed or investigated. But now with the availability of the types of tools being installed to protect an organization's infrastructure, HR can become a valuable customer and partner of the SOC and get regular services to help them evaluate what is going on inside an organization. In many organizations. the policy applied to a web proxy that allows or disallows access to certain types of websites has been contested. In a lot of cases, it is the IT or security department that owns the web proxy devices, so consequently they own the policy. In a mature organization, it would be the HR department that owns the proxy policy and collaborates with the SOC. HR should be the organization that directs and controls who is allowed to access what, as this is a personnel and organizational policy issue. As a customer of the SOC, HR would be given the opportunity to set policy and the SOC would configure that policy and monitor against that policy. When issues arise or requests come in to open websites previously blocked to users, the SOC can either grant that access if it falls within a specified or previously agreed parameter or if in question they can engage HR for a ruling. This is a simple example of how HR can be a vital customer of the SOC. Additionally, the...