The role of the Business Analyst (BA) is generally understood as the stakeholder who is responsible for managing the software requirements. While it briefly adds who a business analyst is, the real role goes beyond that. BA implies from the brainstorming phase of the project to its decomposition. In each of these phases, BA plays a vital and diversified role in bringing an idea to life. However, the way in which the BA views the security aspects of software is the focus of this article.
Understanding about Data Protection Standards and Regulations
To start with, BA’s understanding of the software security standards and it’s applicability plays a bigger role. There are different data protection standards and regulations available in the world. GDPR (General Data Protection Regulation), CCPA (California Consumer Privacy Act), HIPAA (Health Insurance Portability and Accountability Act), PCI (Payment Card Industry), ISO27001 (International Organization for Standards on Information Security Standard) are some of them. These standards and regulations significantly impact the SDLC (Software Development Life Cycle) and corresponding IT-development processes of organizations that plan to roll out information systems’ projects. They also increase the complexity of the functional, non-functional, and technical designs associated with the various business and technical layers outlined in systems. It is a software engineering responsibility to follow basic data protection principles. However, as a BA, it is better to have an understanding of at least a few of these standards and regulations, because the data protection requirements need to be addressed in the planning stage of the SDLC and documented to avoid significant cost overruns and rework later in the SDLC process.
Accordingly, based on the client, the type of the project, and region the software is being developed, the standards which need to adhere may differ. However, upon the selection of one, more or none of the above standards, the specific security-related aspects will differ as well. Hence, the focus of this article is given to how a BA can involve in a generic Secure Software Development Life Cycle (SSDLC) without being specific to the aforementioned security standards. Yet, it must be highlighted that, if a project was undertaken under such a specific security standard, the respective specific security concerns must be addressed by the BA and the rest of the team members.
The SDLC Vs SSDLC
The SDLC is a framework that interprets the process used by organizations to develop an application from its initiation to its closure.
That being said, In general, SDLC includes the following phases:
- Planning and requirements gathering
- Architecture and designing
- Release and maintenance
Simply, the SSDLC will be derived by applying software security aspects to each stage of the SDLC. Business Analyst’s involvement in the SSDLC is further detailed out in the subsequent sections
Generic Security Touch-points
As discussed in the overview, once software security aspects are applied to each phase of the SDLC, it’s considered as SSDLC. Therefore, security touch-points are introduced at each level of the SDLC phases.
The involvement of the security touch-points can be easily demonstrated by the
Gary McGraw’s influential touch-point model as follows,
Among these security touchpoints, the focus is given to the involvement of the BA.
BA’s Involvement in The SSDLC
Security enforced planning and
By praising the selected SDLC methodology; planning, and modeling techniques shall be carried out by deriving the scope into multiple modules and sub-modules which allows easy maintenance and easy management of them. More the modules and sub-modules were derived and separated, more the security of each module can be enforced individually (Rather following all-in-one concepts) for a better-combined security output once all the modules are functioning in a single place. Accordingly, the Business functional architecture of the system shall be designed to fulfill the aforementioned context.
A sample section of the Business functional architecture is attached below for a further illustration
Security Requirements Specification
Security Requirements in SRS
All the requirements elicited for the project will be documented in the Software requirement specification (SRS) document format. Functional and Non-functional requirements captured will be elaborated as spec points under each SRS maintained for each module.
A sample section of the SRS document is attached below for a further illustration
Accordingly, as part of the functional and non-functional requirements gathering process, security requirements shall also be captured and documented the SRS,
A sample depiction of a security requirement is attached below for a further illustration
Security Requirements in User Stories
Apart from the SRS, user stories documents will also be maintained for each sprint. Therefore, security requirements shall also be covered either as user stories or scenarios under the user stories to ensure focus on the security
A sample depiction of a security scenario of a user story is attached below for a further illustration
As an initial requirement gathering step, Use-Case diagrams will be used to identify interactions among actors in a system. In the same mechanism, Abuse cases (also called misuse cases) shall also be identified by modeling adversarial actions to the system
A sample depiction of an abuse-case is attached below for a further illustration
Evil User Stories
Evil user stories are equal to the standard user stories, yet they express what an evil-minded user (abusive user) would do in the system instead of what a standard user would do. These stories highlight what the system is not expecting a user to do. By understanding what a hostile user would do in the product, acceptance criteria and the scenarios can be developed against it to better defend against them.
A sample depiction of an evil user story is attached below for a further illustration
Security Enforced KB Articles
Once the development is done and ready to be deployed, in order to enforce the security in release and the maintenance; procedures and documentation will be used such as Deployment guides, user guides, support team guides, etc.