The most important thing we can do before writing a single line of code is to clarify the division of responsibilities between us and the customer, as well as the classification of the solution and data. What requirements does the customer have, and what requirements comes from the government or other parties? Application security (AppSec) resources should already be part of the team in this phase to ensure that we meet security requirements and expectations.
We must also outline what we will do when a security incident occurs - what requirements are we facing, what is needed for successful disaster recovery, backup, and similar measures, and what will the consequences of downtime be for the customer?
A lack of clarity in our responsibilities and those of others can have huge consequences for a project, so this must be clarified beforehand. It is especially important if companies other than us and the client are involved, as tasks and roles tend to fall through the cracks because everyone thinks “someone else” will handle it.
Most organizations operate with various classification levels for both data and systems. The classification level dictates how data is used, where it is stored, and who can access it. These are key requirements for any development project and must be clarified in advance.
If a catastrophic event occurs, we must know who to contact and what requirements the solution and delivery team must adhere to. This not only includes typical availability requirements but also how long recovery can take, how it should be done, and what is an acceptable data loss.
Misconfiguration is a common source of errors and vulnerabilities, and this also applies to tools. If possible, the team should standardize the use of tools and their extensions, ensuring that everyone follows a similar (and documented) workflow.
A security checkpoint is a control point during a project where requirements must be met before proceeding.