There are many challenges when trying to get teams to collaborate and work well together. Boundaries and barriers block progress. Effective and efficient communication is paramount (if not one of the most important things) and tools should strengthen and lubricate interactions rather than weaken or hinder them. Friction impedes collaboration so it’s vitally important to understand where work happens, who carries it out, and how.
Infosec teams do not operate in a vacuum so optimizing for frictionless collaboration across teams and stakeholders is crucial for everything from Incident Response to clearing security patch backlogs. Infosec Case Management systems record and track work just like other IT service request and incident systems but they also need to be fit-for-purpose as a system of record, one with a strong focus on chain of custody and evidence gathering. When considering an Infosec Case Management system do you start top-down, bottom-up, or middle-out?
What is your decision criteria and evaluation method?
Pivoting on Trust
You may or may not have an ISMS (Information Security Management System) that describes and documents your approach to organizational security. It’s a pretty safe bet your organization already uses a tool or platform for some form of case management: Helpdesk might use ServiceNow, Ops might use Jira, and Engineering might use GitHub.
The assets that security teams protect are mostly orchestrated and managed by other teams, teams Infosec relies upon for a base level of system or service integrity.
These other teams share the overall security risk as they own and administer most of the entities that make up your overall security posture. Information security, and thus organizational resiliency, is dependent upon multiple teams, not just the security ones.
Some may consider case management a stub but it’s actually a nexus for when, where, and how work gets done. The question is then, what work needs to be done and by who? There’s a balance between building and maintaining an isolated (or bespoke) Infosec Case Management system and implementing a secure instance of (or sharing) an existing and fully featured one. The fundamental question underpinning this type of decision often revolves around the security of sensitive case content and access. The classification of and access to content controls how an Infosec team reasons about trust and breaches. It raises questions about who has super, domain, or root admin accounts and why. Although Infosec teams often want their own dedicated infrastructure and stack to partition failure domains, there will always be some form of transitive trust and interfaces with other teams.
So where does this risk lie and how do you mitigate it or balance it with other complexities and overheads? Even if a secure enclave is desired, what then is the best stack and application to run atop it while considering the true risk and jobs to be done?
Trust issues also revolve around whether or not an Infosec Case Management system is fit-for-purpose rather than an afterthought or bolt-on with another product. ITSM (IT Service Management) is a complex undertaking involving many aspects of incident and request management. This can mean multiple workflows, access levels, and customizations or exception handling which often require full-time administration and support.
The ability of a security case management system to integrate with other systems, while itself providing a first-class API for automation, is also key in accelerating response times, enabling rapid enrichment, and fostering collaboration.
It’s crucial that users and operators trust their case management system and can use it effectively. It must fulfill its primary function well and not just be the result of a feature parity race or box-ticking exercise.
System Scenario Mapping
So it comes down to a few options for how to architect and then build or buy an Infosec Case Management system. Decisions should always be made with a clear understanding of your organization’s specific requirements, policies, and unique risk landscape. Some general high-level patterns do apply, each with differing levels of cost, complexity, and operational demarcation for selecting the right platform:
Application scenarios (whether public cloud, private cloud / on-premises):
a) Leverage an existing and native case management system already in use in the organization (making use of institutional knowledge, expertise, and relationships...)
b) Create a separate instance of (a) exclusively for use by Infosec (benefitting as above)
c) Procure and provision a new case management system/platform
d) Use a “second class” non-core case management feature set provided by another security application
e) Build your own
It’s also a good idea to surface and review any existing licenses, contracts, or internal expertise with relevant platforms across your organization.
Systems of record (just like standards) can not work well if they compete, overlap, are misunderstood, or have accessibility issues.
Systems of record should be just that, and diluting them or forcing users to follow a trail of breadcrumbs is counter-productive and disincentivizes their use. Extreme caution is advised whenever considering adding another case management system into the mix. The complexity and hidden costs of running something that is not fit-for-purpose can be cancerous, so caveat emptor.
Tip: When using a flexible SOAR(Security Orchestration, Automation, and Response) platform that understands what its core mission is, you can flexibly and rapidly integrate any of the options from (a) to (c) above, and evolve workflows and interfaces as needs change. By bridging organizational divides you can leverage existing expertise and initiate tasking where the work actually gets done. This also allows you to cleanly and securely preserve privileged access including RBAC(Role-Based Access Control) while relying on your primary IAM(Identity and Access Management) services.
The Lion’s Share
Another question is around usage. Is the majority of work to be performed in relation to investigations, incidents, or lifecycle management? What other teams are involved in actioning or completing work such as collaborating on or updating cases? Does your Infosec Case Management system need to trigger external workflows, touch multiple systems, or involve multiple users external to the security team? What blockers or speed bumps can you avoid altogether just by spending some time modeling and architecting for your optimal outcomes?
If an operator or user is going to record, track, and perform work using a system, the platform usability and efficacy is key. It needs to be familiar, rather than another bespoke thing to learn, and it should engender trust while enabling rapid action.
Better Collaboration, Faster Outcomes
Collaboration works best when teams are unified in their goals and they understand there is psychological safety. This feeling of safety is born of a cooperative rather than a competitive culture. Just as security is a quality of a system, it does not stand alone. Expecting a non-security team to use your bespoke case management system rather than their own breaks their productivity and the conceptual location and familiarity of where their work happens. Once infosec can “skate to where the puck is going to be” things happen faster and the advantage is gained.
The quality of a case management API, or lack thereof, can be a deal-breaker for many. Automation and non-local orchestration are required in modern Infosec for a whole host of security workflows. Security is a multi-disciplined affair that’s rarely restricted to any one silo. As things speed up, automation is at the fulcrum of defense and requires a multi-pronged defense-in-depth approach. The organizational network of humans and machines that transforms information into actions uses many touchpoints. When choosing an Infosec Case Management system, irrespective of whether you use a lightweight feature comparison matrix or a more heavyweight requirements gathering and evaluation process, being able to quickly build secure overlays and grow or prune ephemeral connections is now table-stakes for Infosec teams… but it’s not quite case closed yet.
Summary and Recommendations
Security teams of even modest maturity need a location to record, action, prioritize and report on their work. Chances are that your organization already has a tool that adjacent teams are using for a similar purpose (such as Jira, ServiceNow, Zendesk, or Github). Before investing in another system of record, try hard to make an existing platform or investment work for your security needs.
If a dedicated platform is a must-have, a pure-play Security Case Management system (for example Tines cases or TheHive) will likely provide more value in the long run than one that comes bundled into a larger offering. What do you think, case closed?