Eva Belyaeva, Security Vision
Once upon a time the nations of developers and security professionals lived in peace, but everything changed when the regulator decided to regulate their processes too.
1. common language
Or rather, its absence. Specialists often exist in their own specific coordinate systems, where priorities are given to different, at first glance not overlapping tasks. For example, what is the task of a good security professional? Most likely, product certification. An excellent security engineer, as well as an excellent developer, has the task to release a high-quality and secure product, but it is still necessary to get to such a stage of evolution.
So what are the tasks of a good development team? Most likely, the creation of new functionality, which in particularly severe burnout cases turns into a ticket system task counter.
There are different ways to motivate both the developer and the security guy. They have something in common, such as motivation to get a long-awaited certificate; but such motivation is usually handled by the company. As for the softer motivation - often such a driver of progress becomes a very motivated person ‘with a burning eye’, ready to destroy and break the code in front of him (sometimes it upsets teamleads), but in any case, this work is quite creative.
The main conflicts occur when a security engineer with a specific task and a developer with a long tail of backlog enter the warpath, and it is not clear at first sight how exactly they should join forces and why the task is actually common.
In particular, some problems start with suspicions: will the developer introduce a malicious commit, how well versed are the leads in commit and merge security, how many libraries are used in open source development? One fine day it may turn out that the usual tools are compromised, which clearly highlights the need for code analysis.
2. POC and how to prepare it
The second stumbling block is providing evidence as the last bulwark of convincing a disagreeing colleague.
It is often not enough to argue ‘here is a goal, there is a bug on the way to the goal - the bug must be removed’. This logical sequence, although reliable, can be full of nuances. The development team has an impressive number of counterarguments for all these cases: the stars will never align in the right sequence so that the attack will happen; no one will ever think of doing such a thing; and even a physical attacker will never, ever, really, really get to the source code/opportunity to substitute a file/substitute the necessary one. And anyway, it's legacy, what are we going to do?
That's why every bug should have a POC behind it, if that's not enough - a POC with reproduction examples, and if that's not enough - a POC from a pentest that caused the software to not work. But if even this argument does not convince the developer, the last resort is the art of translation from Russian to Russian - from security to development. If you are lucky, this mysterious kung-fu will be performed by a specially trained person (more about this later), but let's be honest: very often you are not lucky. Without this magic, you can never, alas, solve the problem.
Because no matter how critical the bug is, no matter how important it is for the certification of the product as a whole - as long as the problem representation is not transferred into the coordinate system of those who have to deal with this bug, the matter will never move from the dead point. However, nobody is insured from the fact that your dispute will move to a new plane even after providing ironclad proofs - now the security engineer will have to justify and defend criticality, and then - deadlines, and then....
3. code analysis
Since we have touched upon the areas of responsibility (and competence) at least indirectly, we can talk about the most pressing issue: who should build the process of code analysis into the product development process? Who will be responsible directly for implementation? Static analysis is good because it can exist separately and give a lot of reliable and not so reliable remarks together with the statistics of code base coverage. Dynamic analysis is not so simple - such checks require leaving ‘taps’ in the code itself, as well as the possibility to build the product exactly for the purpose of testing - it can be a patch, launch conditions, some other variant convenient for the security engineer but almost never satisfying the development. Why so?
There can be a lot of problems indirectly or directly related to this (without irony) difficult task. High workload or lack of competences are the most common ones. However, it's worth noting that many arguments that boil down to ‘let's just do it ourselves’ will sooner or later lead to a way where the developer will realise by many or not so many trials and errors that this approach is useful (and convenient), first of all, for him/herself.
4. what unites?
Obviously, something common. A common friend or a common enemy. As for the enemy - it is not uncommon to build wonderful and long-lasting friendships with colleagues after joint readings of the regulator's requirements. Sometimes it is possible to organise a whole stand-up show and role-playing games - when one team reads the requirements and the other tries to guess what was the point of it all.
Go through fire and water together. Let at least one SDL launch at least within one product to sharpen the sharp edges on all the stumbling blocks - and the teams themselves will not notice how tossing the bug, like a hot potato from hand to hand, will move to a healthy and, most importantly, useful and enjoyable process of searching for vulnerabilities in the code. And where is our long-awaited coverage report there, by the way?
Seeing the first results of the work in general is invaluable - it's not always obvious in words what a new format can lead to. And even more so, at some point you get a chance to influence these very normative documents and the key values and settings of code analysis - who would miss a chance to influence FSTEC and bring the regulator closer to reality.
Is it possible to make everything good at once? Of course, there is a magic pill for such a case, and even more than one. Firstly, no one and nothing will stop a developer and a security engineer from doing well if they really want to. When teams are initially interested in the quality of the product, in the efficiency in eliminating problems, the question of confrontation does not even arise.
In the process of interaction many sharp corners are erased, that's why they say that for success application security becomes a full-fledged part of the team, constantly in touch and up to his ears in the code, ready to tear through the thorns to the cherished Secure by design.
Secondly, if we get down from heaven to earth and present a more realistic picture, one marvellous Pokemon specialist - security champion - helps to establish competent interaction. But we will talk about that some other time.
