Building Better Security: Part 2 – Secure Analysis

Diagram of SDLC with Analysis highlighted

In the first post in this series, I wrote about the fact that security is not a one-time task. It must be part of your whole development process. This week I want to share some thoughts about security in requirements analysis.

The “normal” SDLC

Although there are variations, the SDLC generally consists of the following phases:

  1. (Planning and) Analysis
  2. Design
  3. Implementation
  4. Testing (and Deployment)
  5. Maintenance

Testing is often included in the implementation phase. But that downplays the importance of testing, instead of giving it the right priority.

The SDLC phases exist even if you use an Agile approach. The difference is size and scope. Instead of tackling the whole system in each phase, you focus on smaller parts in each iteration.

The need for security requirements

The requirements analysis phase is when we identify what the system must be able to do. This is usually documented in some kind of business or software requirements specification. In the case of Agile, this will be the feature list for the iteration.

How do we can include security in this phase? Simple (in theory): we need to identify our security and privacy requirements. This applies regardless of whether you are planning to buy or build the system.

We all know that the more information we have at the beginning of the project, the better. If we know the security requirements from the start, it is easier to build them into the system.

Myth: Security requirements are non-functional

Stop! Don't say that!

Fact #1: Security is everyone's job.

Fact #2: The security of your software has legal implications. Legal requirements are always part of your analysis, so why is security any different?

This may be a mindset change for many stakeholders. Users and owners focus on what the system should do, rather than what it should not do. And they have misconceptions about the impact of security on usability or functionality.

But [insert name here] is not a security expert

In many companies, it is the job of the business analyst to identify the requirements. But what if the business analyst has very little knowledge about security?

Read fact #1 above. Everyone involved in the development process gets some training in security.

Not everyone needs the same depth of technical training. Your business analyst doesn't need to compare different types of encryption. But everyone needs a foundation. That will create awareness and a shared vocabulary - which will improve communication.

Identify the security requirements

The first step is to identify the legal and industry requirements. In South Africa, think about POPI requirements. If you service the European market, remember GDPR. And there is similar legislation for North America and most countries.

Then consider requirements based on previous incidents and known threats.

Secure requirements analysis, like design, should follow the CIA triad. No, that's not about spies and James Bond. The CIA model focuses on Confidentiality, Integrity, and Availability.

And, of course, any software development project should specify performance criteria. So you should define the minimum acceptable levels of security quality.

Over time, you will develop security standards and policies specific to your systems. These will become part of all your requirements.

Useful reference

Here are two very useful references:

Read the next post in this series: Building Better Security - Part 3: Secure Design.

Leave a Comment

Your email address will not be published. Required fields are marked *

Thank You

We're Excited!

Thank you for completing the form. We're excited that you have chosen to contact us about training. We will process the information as soon as we can, and we will do our best to contact you within 1 working day. (Please note that our offices are closed over weekends and public holidays.)

Don't Worry

Our privacy policy ensures your data is safe: Incus Data does not sell or otherwise distribute email addresses. We will not divulge your personal information to anyone unless specifically authorised by you.

If you need any further information, please contact us on tel: (27) 12-666-2020 or email info@incusdata.com

How can we help you?

Let us contact you about your training requirements. Just fill in a few details, and we’ll get right back to you.