With minimum requirements in mind, security technology teams can begin to develop the scope of an integration project. The scope is important to ensure that operations, security technology, IT, and the vendor are all clear on the goals of the project. Having spent over 20-years building integrations with security systems, we have developed a lot of scope documents over the years. The best piece of advice we can give when developing these scopes is to focus on the user story.
Focus on the User Story
The user story is a simple, non-technical description of what the end-user, in this case, the operator in the command center, requires from this integration. It might seem simplistic and repetitive, but many of the people involved in these projects have never spent a day working in a command center. That said, it’s understandable that they cannot make assumptions about what is important.
With highly technical teams it’s very common for integration projects to focus on the technical implementation, i.e. opening ports, network configurations, etc. Though these are critical tasks on their own, they more often “become the project” but are not a part of delivering value to the end-user.
AN EXAMPLE OF A SIMPLE USER STORY MIGHT BE:
Below is an example of a user story for a project to integrate with a business risk alerting service.
Operators in the command center are responsible for monitoring alerts from our business risk system that provide updates on outside events that may impact our offices. The type of alerts range from civil disturbances such as a protest to weather alerts that might impact travel and deliveries. Today, these alarms come into a central email box that the operations teams have to monitor in addition to their other security events.
In this first paragraph, we have defined what this system does and how it is managed today.
There is no way to properly track who responds to these alerts, what actions they need to take or to enforce any internal SLA. The goal would be for these alerts to be sent to our security response system, where we could associate events with action plans and prioritize these based on the type of event and proximity to our primary campus.
In this second paragraph, we stated the operation problem along with a simple goal.
The information required for the operator to respond properly is:
- Time of the event
- Type of event – e.g. protest weather warning, traffic incident, etc. Location impacted by this event – e.g. building name
- Specific location – we would like to see this on our map
- Extensive details about why this event was triggered
Here we defined the basic information the SOC needs
Additionally, the manager of the SOC would like these alarms and their responses automatically added to the daily activity report that tracks all of the other security events on the campus.
Notice how this user story focuses on the problem and the desired outcomes, not on the technical implementation? How the security technology and IT team choose to solve this problem technically can then be developed with a clear understanding of the desired outcome.
You’ve chosen your response platform, finalized your integration requirements, mapped out alarm importance and triaging, and scoped your project—up next, learning the details of standards-based and native integrations. Read more in our full whitepaper, Integrating Your Security Operation: A Roadmap For Connecting Technology to Deliver Optimum Operational Value.
Related Blogs:
