When creating a cybersecurity services catalog, security teams must ensure the contents are simple to understand, expectations are set appropriately and everything is aligned to business needs.
This piece provides best practices for creating a cybersecurity services catalog, including pitfalls to avoid along with templates and examples that can be referenced throughout the organization.
Cybersecurity Service Catalog Best Practices
When building a cybersecurity service catalog, proper planning is essential. For example, setting clear expectations helps the cybersecurity team be more successful in delivery and the business better plan around a level of service, accountability and
cost. The cybersecurity team should strive to take a realistic approach to what will and will not be offered. The catalog should align with the cybersecurity team’s technical and intellectual abilities, and it should also be customer-centric.
When creating the menu of security services, it’s important to:
- Understand the overall purpose: It sounds simple, but you should be able to answer why the service catalog exists and what the expectations should be. Think of it as a mission statement. This step is beneficial both for those creating
the catalog, as well as those consuming its contents.
- Be able to articulate your goals to the business: The catalog exists to help the company, but what are some of the problems you’re trying to solve with the catalog, and how do you measure its success? It’s important to
be able to explain the catalog’s value to the business.
- Talk with business units: Establishing communication with business units is essential for success. Learning what they want, and need, helps with planning the catalog and providing essential services. It’s easy to assume cybersecurity
knows what is best, and while the team certainly has a good idea, it’s best to speak with the business from the beginning.
- Focus on ease of use: Content that is grouped together with similar services will help employees find what they need easily. Create clear groups and then place available services within them (examples are outlined in Figure 1 below).
- Use language understood by the consumers of the catalog: It’s easy for security teams to get wrapped up in technical jargon. However, this only confuses users and can lead to requests that do not align with what the consumer
really needs.
- Keep realistic expectations: The security team can’t be everything to everyone. Assessing the team’s capabilities and creating a catalog of services that align with its real-world abilities sets the team up for success.
In addition, consumers get what they want done well versus having to constantly deal with errors and omissions. Start off with a simpler catalog aligned to specific team abilities and then add more advanced capabilities after the team gains more
experience and the business has had a chance to consume and offer feedback.
- Establish channels for feedback: Constant feedback and the ability to iterate will help the security team learn and improve. Understanding what went well and, more importantly, what did not will help the security team learn from mistakes
and make needed changes.
Cybersecurity Services Catalog Pitfalls to Avoid
Constructing and maintaining a services catalog is not a one-and-done affair. It usually requires several iterations to ensure it improves over time. The services catalog won’t be perfect from the beginning, but some pitfalls to avoid include:
- Metrics-only focus: Completing a service within a defined SLA is easy to track and, on the surface, all those met SLAs may make it appear as though everything is working well. However, is what was delivered really what the consumer
wanted? It’s crucial to focus on what is important to the requestor. This is where open lines of communication and feedback is needed. Include metrics, but also follow up on the deliverable outcome as both are needed.
- Unorganized content: Group services into categories that can be referenced easily. Within each major category, consumers should be able to find the related services they need.
- Overpromising: Trying to offer too much too soon with services that are more advanced than the team can handle is a recipe for frustration—for both the team and the consumer.
- Unnecessary complexity: While this should be obvious, it still should be top of mind to avoid. If a goal is for employees to serve themselves through the process, then it cannot be too complex.
- Lack of workflow navigation: Many commercial solutions offer service workflows that enable business units/consumers to follow along and track progress. Even in the absence of an online system, the catalog will best benefit consumers
when they can see/track the process of a deliverable from start to finish.
- Failing to define responsibilities: Both the business and security team should know what their responsibilities are. In addition, the workflow should define what happens along the way. If there is a need for escalation or sign-off,
it should be clear where that falls in terms of responsibility. Don’t let something fall by the wayside simply because a key person is unavailable.
- Failing to include business justification: Note who in the organization has the authority to approve the request and be sure that is included in the workflow.
READ: Infosec Project Management Best Practices
Cybersecurity Catalog Content Examples
No two organizations provide the same services within their cybersecurity catalog. The clearer the catalog, however, the better the outcome for both the technical team and business units. Typically, each entry in the catalog will include the following:
- General service category: This is the top-level grouping for the service.
- Service name: Use a name the business can easily comprehend. For example, instead of titling a service “Smishing Testing,” consider using something like “Social Engineering Awareness Testing.”
- Service description: Provide a high-level description of the service.
- Service features and functions: Expand the description and offer a more granular explanation about the service.
- Service dependencies: Include any dependencies on third parties, internal teams and other systems.
- Service level: Service-level expectations. For example, “The service will be implemented within seven business days,” or “The response to service issues will be within 24 hours.”
- Service approval: Who is authorized to request a service and who approves the request?
- Service cost: Estimate the cost for the service, which may be charged back to the business unit, if applicable.
- Support for service requested: Include points of contact for questions and troubleshooting.
Figure 1 provides some typical examples of general service categories and the services under them.
|
| | | | |
Security Service | Conduct third-party review and assessment | Provision roles and permissions | Create policies and procedures | Secure hosts with endpoint solutions |
Security Service | Secure remote access | Audit and decommission accounts | Review third-party and system dependencies | Conduct vulnerability assessments |
| | | | Source: IANS, 2022 |
Cybersecurity Services Catalog Template Examples
Security teams will want to make the catalog their own. However, the following resources from NIST and CISA can help guide teams in their journey:
READ: A Guide to NIST Standards and Frameworks
How to Get Started
To ensure your catalog works well for both the cybersecurity team and the business units consuming the services, it’s important to:
- Spend time planning out the services: Start slow with services you know you can deliver, and then iterate from there.
- Communicate with the business: It’s important to get the business units involved both upfront, while the catalog is being created, and after the fact, to ensure you get their feedback and ideas for improvement.
- Be clear and use easy-to-understand language: A catalog built with technospeak won’t meet its goals because business units won’t understand the services and the team likely won’t be able to deliver successfully.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.