How can you elicit and analyze requirements in a cybersecurity or privacy-driven domain?

Security requirements are crucial for protecting an organization's assets, data, and reputation. They outline specific security measures to safeguard systems, networks, and applications. Understanding the context is essential for tailored and effective security measures. This includes understanding the organization's assets, threats, and vulnerabilities, as well as risk assessment and risk appetite. Once the context is understood, developing use cases, abuse cases, threat modeling, and risk assessment may be necessary. Security requirements ensure compliance, guide security control measures, identify and address risks, enable continuous improvement, and mitigate cyber threats and privacy breaches in a holistic manner.

Researching the cybersecurity and privacy landscape is essential for compliance with laws, standards, and threats. Assumptions need validation, and constraints may involve budget limitations. Dependencies affect data flows, requiring coordination. Stakeholders include patients, providers, regulators, and administrators. Privacy concerns drive stringent requirements. In the cybersecurity landscape, HIPAA compliance is paramount, with encryption, audit trails, and access controls. Knowledge of threats like ransomware informs security measures. Understanding this context ensures data governance requirements align with the organization's unique needs and challenges.

Eliciting and analyzing requirements in a cybersecurity or privacy-driven domain is an ongoing process that requires collaboration, expertise, and adaptability to address emerging threats and regulatory changes.

It is also very important to gain insight into the threat landscape specific to the industry and region of your project and familiarize yourself with the organization's incident response plan

Before ever starting, make sure you have a thorough understanding of the core domain you are working in and the issues that the domain, not just your customer, faces. This level of knowledge will set the tone for the requirements gathering sessions and will be foundational for confirming with your client that you are capable of capturing their requirements. You would not be there if they didn’t trust you to begin with so build on that trust to demonstrate expertise.

Industry-standard methods for gathering and assessing security requirements depend on project factors like scope, complexity, and stakeholder involvement. Use cases document user-system interactions, revealing threats and vulnerabilities. Abuse cases, which can be highly effective, focus on malicious interactions to aid vulnerability identification. Threat modeling assesses threats and facilitates risk prioritization. Risk assessment evaluates risks. Interviews, workshops, and surveys gather stakeholder insights to supplement these methods. Microsoft Threat Modeling Tool and OWASP Threat Dragon can help identify and analyze potential threats and vulnerabilities in a system.

Privacy driven domain always required additional efforts when it comes to requirement elicitation and gathering stage of the project. In my opinion BA must prepare Stakeholder(SK) Register and Power-Influence Grid to leverage this analysis while conducting meetings for requirement gathering. Delphi method of conducting group interviews of selective SK will make it most useful when you are dealing with cybersecurity related project or the one which requires confidential details to be disclosed within the tightly coupled group of people on need-to-know basis.

In my experience, brainstorming sessions to gather requirements and map them using a mind-mapping tool (for example Mind Map). That way visual presentation can help facilitate discussion. After that prioritize based on value metrics and send them using surveys, so qualitative and quantitative data can be received without any influences, protecting privacy.

To my experience, expert consultation is a very useful and effective method in these kind of projects. Engage with cybersecurity and privacy experts to provide insights and guidance on specific requirements, especially for complex or specialized projects.

Build on existing systems rather than reinvent the wheel every single time. Review existing documentation such as system specifications, data flow diagrams, and privacy policies. This can help identify current security measures and areas that may need improvement. Understand and analyze the relevant legal and regulatory requirements related to cybersecurity and privacy. This includes laws like the General Data Protection Regulation (GDPR) in the EU, the California Consumer Privacy Act (CCPA) in the US, and industry-specific regulations like the Health Insurance Portability and Accountability Act (HIPAA) for healthcare, just to cite, some of them.

You can start by identifying conflicting requirements, constraints, or objectives. Then prioritize requirements based on deferent criteria to realize which requirements are mission-critical, compliance-related, or have the highest impact on security and privacy.

There is no perfect system but systems which tend to be perfect. Perform a risk assessment to identify potential threats and vulnerabilities. This should consider both internal and external risks and should be done in consultation with stakeholders. Developing critical use cases and scenarios to understand how the system will be used and where potential security and privacy issues may arise. This can also help identify functional and non-functional requirements. Once the requirements have been identified, they need to be prioritized based on factors like risk level, cost, and stakeholder needs. They should then be validated with stakeholders to ensure they accurately reflect their needs and expectations.

Documentation related, whether it is version, upgrade or need assessment needs to be maintained and cannot be overemphasized. Cybersecurity and privacy requirements are not static. They need to be continuously reviewed and updated as new threats emerge, technologies evolve, and business needs change. Throughout this process, it's important to maintain clear and open communication with stakeholders to ensure their needs and concerns are being addressed. It's also crucial to document all requirements and decisions for future reference and accountability.

Evaluate the security and privacy risks associated with third-party vendors and suppliers. Ensure that requirements address these risks. Also it's very important to develop and document incident response and recovery requirements.

As a BA you only work with the information that is provided to you. You have to work with business and developers to help them see what makes sense for them, you DO NOT make decissions instead of business. Gathering information is difficult, responsible people will always run. If upper management constrains them to participate, they will MOST likely use confusing language or very technical ramblings that not the BA nor the developer can make sense of. Just constraining them with calendar entries is not enough. The CLEAR factor of information in consulting between the client and developer is the KEY. BA should insist on clear and signed off information from both sides, and have a way to directly reach upper mgmt about quality of information.

In cybersecurity and privacy, it's important to foster an environment that balances innovation with effective risk management. This includes identifying who is responsible for addressing risks, especially when using open-source software like Python and R. In such a setting, business analysts should be able to experiment with new ideas while maintaining a strong focus on security and privacy.