A security assessment is the most common way to improve and validate the security of almost any system or software. An assessment is easy to order and gives clear results. Furthermore, it may even be a requirement for compliance.
Using an assessment to identify and correct security issues makes sense. Unfortunately, too often, there is no further use of the results. Similar issues can pop up again, for example, in the next version or in another integration of the software. Running regular assessments can prevent this and may eventually lead to a reduction in assessment findings. However, this is quite an inefficient way of learning to make software more secure. The resulting process is unlikely to be efficient or able to cope with continuous changes which are inevitable.
The traditional way of completing a security assessment towards the end of the process is challenging for the project. As the assessment is done when the software is almost ready, the time spent on it results in a delay in sending the software to production. It is normal to expect the assessment to have findings and correcting them is an essential part of software creation. Typically, only minimal corrections are made due to a tight schedule, and therefore the first version is released with known security issues. The large number and size of iterations due to security often indicate that the development process could be improved.
Simply asking developers to design and implement plans more securely does not offer much improvement. If this worked well, the security puzzle would have been solved a long time ago. This kind of direct approach can work only if the development team is already mature at implementing their security work.
Moving beyond assessments
Most daily security problems are quite predictable (contrary to popular belief). Esoteric security issues can be near impossible to predict, but these are really only a tiny fraction of all security issues. Some problems can be seen even before development starts, and many before implementation. Predicting security issues requires some experience and time. A big part of improving security work is to make it common practice to spend time identifying likely security issues. Involving a security expert really helps when predicting security issues, as they know a lot of typical issues from the past, and they may know other relevant information due to other contacts they have.
Bringing in security predictions from the outside seldom works. Such information is perhaps understood, but too often not acted upon. In order to make the predictions credible and accepted, they should be created together with the development team. In this process, security experts should bring in ideas and encourage teams to explore further issues.
In an ideal world, a security expert's work starts with the product owner. The product owner has several matters to take care of and security is only one of many. Helping the product owner see potential issues early enough is an important part of a security expert’s job.
Risk analysis and threat modeling (your terms for these may vary) make security more visible for developers. A security expert should not produce risk and threat information alone, but this should be done together with the rest of the development team, for example in workshops. This ensures that relevant results are in fact both understood and accepted.
Being able to make sense of security to other is key to a security expert’s success. When successful, a security expert’s contribution is taken seriously. At that point, the security expert can really influence the development at appropriate times (typically in one-to-one discussions, workshops and during coffee breaks).
A security expert’s role is to enable this security work, not to do it all. A security expert cannot work in isolation, as the work requires a lot of communication with the development team. This allows the development team to learn about security and avoid a security bottleneck occurring anywhere in the process.
When security work is integrated into development, the role of the security assessment can change. The final assessment is now a combination of a quick review of the work already done and, perhaps, testing the very latest of the features and corrections made. The assessment is no longer a challenge to schedules, and it is natural to think about the development process when discussing the security issues found.
What Wapice offers
As you might have heard, Wapice is now also offering dedicated security services, in addition to the hands-on security expertise, which has been proven over the years. The services enable a modern approach to security and are simple to get started with.
Two of the services can get you started with bringing security into your development work. The different approaches on these services ensures we can help whether your strategy needs a quick ramp-up of security work or an adoption of secure development practices to be implemented internally or by an external entity.
Our secure development support services offer a security expert for the development work. The security expert will participate in the development work, helping in all steps relevant to security. The security expert can, for example, participate in user story creation, facilitate and support threat modeling workshops or support in security test automation.
Secure Development Life Cycle (SDLC) coaching improves development processes to provide better security. A big part of this is to ensure that security work fits into the existing development process. Work can also include improving the development process itself if it is found to need improvement. Improving a process can take time, so coaching typically spans over longer periods of time. There will be a separate blog posting looking more into SDLC later.
Having said that, we of course offer pure security assessments as well. Selecting Wapice as your security assessor makes sure you won't be left alone with the results.