The 5 most important steps for the security of the proposed SW architecture

Rather than a criminal sitting behind a computer in a dark lair, you will be dealing with various directives, GDPR, writing NFRs (non-functional requirements) and similar paperwork. And there’s a lot of it.

So what to focus on? In the following lines I have written a short (and certainly not exhaustive) list of activities that such an architect or analyst should take into account when designing and analysing a system in the case of security.

Identify the minimum safety requirements

These may be based on both customer requirements and applicable legislation. In other words, put together everything that can affect the application.

• It will make a difference if you design an intranet application for a few users or a portal accessible to the whole world.

• The customer may also require that the data remains only in the Czech Republic or the EU. So will you choose to host it on your own server or use some cloud?

• Is it a subsidiary of a foreign organization that requires you to use certain components or is it a requirement in their guidelines to use only two-factor authentication?

• What about legislative requirements? For example, the aforementioned GDPR?

Get maximum information about the application you are developing

What functionality will the app actually have? How do the previous general requirements relate to them?

• Will users log in using a form, or can their identity be taken from the domain account they are logged in under on the computer?

• How sensitive data does the application handle? Do you know their classification?

• What are the potential threats in the application?

Analyse the risks

Everything you’ve learned so far will come in handy in your risk analysis. You’ll need to define where your risk comes from, assess the potential damage that could result and design measures to prevent it. And it’s up to you, and more importantly your customer, to decide how to approach it. Limiting some risks can be so costly compared to the potential damage that can result that it’s not even worth it. On the other hand, you can often find threats that deserve to be covered by several independent measures.

List NFRs (non-functional requirements)

Basic non-functional requirements include performance, scalability, reliability, extensibility, sustainability, manageability and security. You need to write down what and to what extent each requirement will be met. Since some are mutually exclusive, you will again have to choose different trade-offs in agreement with the customer.

• Log management (i.e., how and what will you log, for how long will the logs be backed up, and after what period will they be deleted)?

• How will you ensure time synchronization on all devices in the system?

• How will you handle application backups?

• How will you deploy a new version of the application?

• Will it be possible to affect running the application online by changing parameters?

• What third-party components should be chosen? Only the proven ones with the certification from major vendors? Paid ones? Opensource? What about licenses?

• And there are many other requirements…

Verify the proposal

Have you finally got everything listed? What if there’s a mistake in your proposal? Software development includes a testing phase to find bugs. It is advisable to do this at this point as well. Finding such a bug at the end of development could cost you a lot of money, because redesigning a poorly designed system is not easy. But it’s still better than a potential attacker discovering the bug in live operation. So what should you do?

For example:

• Go through the proposed UML, UC, ER, Dataflow diagrams, … and analyze them from a security point of view.

• Try to imagine how the system will react when a threat appears. And model a similar situation.

• When a problem occurs, how do you restore the system to run properly?

• How do you find out information about what happened? Do you have any audit logs?

• Have you selected third-party components and services? How is regular updating ensured and who will check for errors?

• Now that you have written the NFRs, have you defined acceptance criteria? Do you know how each requirement will be met? Does also the project manager know and takes this into account?

• Have you ensured the system is sufficiently documented and individual users will know how to use it? For example, who can set user rights and how?

Have you read this far? I’m sure you’ll agree that these are not groundbreaking ideas. But, hand on heart, on which project is application security thought about systematically and then the recommendations made are followed in the development and management of the system? Therefore, it is necessary to remind ourselves of the most important points from time to time. And the remaining ones, which I haven’t even mentioned, you will surely figure out on your own.