Nathan-John Augustyn
5 August 2021

Data breaches are on the rise in 2021 and Covid-19 isn’t deterring cybercriminals. In the United States, the FBI reported a 300-400% increase in cybercrime during the pandemic. Estimations indicate cybercrime will cost the global economy over $6 trillion in 2021.

In South Africa, data breaches are becoming a common occurrence with well-known companies making headlines. Most notably:

• In 2016, Ster-Kinekor leaks +/- 6 million customer data due to a flaw in their website,
• 2017, Dracore Data Sciences sells data of over 50 million South Africans to a real estate company and the database leaks online,
• In 2018, Liberty suffers a massive data breach perpetrated by a hacking team that ends up demanding a ransom for the stolen data,
• In 2020, Nedbank suffers a data breach due to a 3rd party vendor that issues SMS and emails. Estimates indicated that potentially 1,7 million Nedbank clients had their personal information leaked.

These are only occurrences that were made public, but who knows how many other breaches took place. That’s why we’re looking at the role of a business analyst in cybersecurity to investigate how to prevent breaches.

How does this impact the Business Analyst?

The Business Analyst elicits the requirements from the client, analyses the existing process, and defines the to-be process. They also define the requirements document which eventually becomes the basis of the solution.

Additionally, as any Business Analyst has experienced, they act as the custodian of the relationship between business and IT. As they gather requirements from the business, they’ll work with the development team to translate those requirements into a technical specification.

This puts the Business Analyst in a key position to bring security awareness to projects/initiatives right from the very beginning.

The Role of a Business Analyst in Cybersecurity

When considering how this impacts Business Analysts, the onus is on us to educate ourselves, even at a high level, about cybersecurity. There is a slew of resources online to get you up to speed like documents, webinars, courses, and videos most of which are free. However, if you’re looking to spend some money the International Institute of Business Analysts (IIBA) has started introducing specializations. They’ve partnered up with the IEEE Computer Society to create a cybersecurity specialization.

From a practical standpoint, I realize that the learning curve might be too great for non-technical Business Analysts to grasp all the concepts in the cybersecurity space. I’ve been thinking of something that anyone can perform to bring security awareness to a project namely threat modelling by facilitating discussions among their technical teams.

Threat Modelling

Threat modelling can be an easy and fun exercise anyone or a team can perform. I’ve recently started reading a book Threat Modeling Designing for Security written by Adam Shostack a former program manager at Microsoft and threat modelling expert. The book describes a four-step process for threat modelling:

Step 1: Modelling the system

Let’s assume you’ve reached a point in your project where you have the model of the proposed solution or system which you’ve drawn on a whiteboard during a meeting with your technical team. Additionally, you even have a cybersecurity expert you can leverage.

Let’s model a simple system:

We have a front-end, hosted on a web server, which communicates with an API (might have some business logic inside it) and which writes to a database.

Step 2: Finding threats

As a foundation familiarise yourself with STRIDE. STRIDE is a mnemonic and model developed by Praerit Garg and Lauren Kohnfelder at Microsoft for identifying computer security threats:

• Spoofing: pretending to be someone you’re not.
• Tampering: modifying or tampering with things you’re not supposed to.
• Repudiation: being able to prove that someone has done something.
• Information disclosure: exposing information to people who aren’t authorized to see it. Like a data breach or data leak.
• Denial of service: is an attack to make a system unusable.
• Elevation of Privilege: when a user or system component can do things they shouldn’t.

There are many other models that you can use but I find STRIDE to be the most useful.

In the book, Adam Shoshack uses a card game called Elevation of Privilege which you can play with your development team. I’m not going to delve into that for this example, however, you can find the card game here. You can also find instructions to play it remotely here.

Back to your diagram, with your technical team brainstorm how STRIDE fits into your model. Additionally, try and identify as many feasible threats as you can.

Step 3: Addressing those threats

There are a handful of actions you take namely:

• Mitigating threats: making it harder for attackers to take advantage of a particular threat.
• Eliminating threats: completely removing the possibility of the threat by eliminating features.
• Transferring threats: transferring the risk to the customer, or an insurance company.
• Accepting the threat: accepting means fully accepting the risk and the consequences. This could be because you don’t want to turn your organization into a police state or because the costs of addressing it would be too high.

During the session, you’d ideally want to go to a granular level but for this example, I’ll keep it basic. Perhaps during your session, the technical team identifies the below threats fit into the model and add some strategies they can use to address the threats:

Strategies:

• Spoofing: maybe spoofing fits into the front-end of the model because user credentials can be stolen and the team decides the appropriate countermeasure would be to implement multifactor authentication.

• Tampering: also fits into the model from both a front-end and communications between the systems. The team decides to use strong cryptographic protocols, sanitizing user input to mitigate SQL Injections and Cross-Site Scripting (XSS) attacks.

• Repudiation: falls into all systems and the team decides to implement secure audit trails and digital signatures.

• Information Disclosure: something that could fall into configuration files in your API and especially the database. The team decides to encrypt configurations or store them in a secure vault and encrypt sensitive information on the database.

• Denial of Service: maybe your team feels the network can be flooded with requests from the front-end to the webserver. The team decides to implement bandwidth throttling techniques and filter/validate input.

• Elevation of Privilege: this could fit into both your business and system model. The team decides the best countermeasure would be to segregate duties for users, user accounts, and system components by following the least amount of privilege approach.

Step 4: Validation

Now that you’ve listed all the possible threats and mitigation strategies go through it again and make sure you haven’t missed anything or whether the threats are feasible.

Validation shouldn’t be a once-off process though. New threats are introduced on a daily basis as technology advances. To be honest, cybersecurity specialists are only playing catch up with cybercriminals in this day and age. Ideally, you’d want to review your systems on a regular basis and this might not fall in the scope of the Business Analysts but as a BA you’ve already provided your team with a good foundation.

How Integrove can help you

At Integrove we take cybersecurity seriously, which echoes throughout our service stack. While we’re helping you uncover and deliver value to your business, we’ll ensure that it’s done with security in mind. Contact us today to find out how we can help you.

Contact Us