In Canada today, the shortage of information security specialists is estimated at 30,000 employees. Experts believe that in the near future, up to 100 thousand companies will have problems hiring such specialists. What to do? It takes a long time to train specialists of your own, but it is expensive and not always easy to take them from the market.
The pandemic and mass move to a remote location helped a little in this regard: it has become unnecessary to be present in the office, to be listed among employees to be in the team. Outsourced IS services have become more popular, especially in narrow areas, including secure development and DevSecOps. In this piece, Ethan Taylor, a leading architect at a cybersecurity company, will talk in detail about whether it is realistic to build a proper and complete secure development process by outsourcing, as well as what options even exist in this field.
And we’ll look at three options:
- Building a process completely outsourced;
- Completely outsourcing to DevsecOps using the company’s own resources;
- A combined approach. Let’s estimate the advantages and disadvantages of each of them and find out together which one is optimal.
Approach 1: Process completely outsourced
This variant seems easier by default. The advantages are immediately obvious: there is no need to look for internal resources and spend time on finding highly qualified personnel, spend the budget on a new team, there is no need to train or “grow” anyone, and so on. We immediately get a full team of specialists who are ready to build for us all the necessary processes and automate all the integration with the development. It sounds like an ideal plan, but in fact it is somewhat different.
To begin with, an outside company does not know all the nuances of your internal processes and will constantly stumble over seemingly elementary things that you have already done a thousand times. As an example, the restriction of network connectivity between systems, even located in the same network segment, which applies to different organizations. People from the outside with a lack of experience can be difficult to work with, you can not immediately and fully fill out an access request, to describe the architecture and the network diagram in the format of the client company, and so on and so forth.
And this is just one technical point, but the most important role in DevSecOps is the process that involves the interaction between the participants, in which difficulties can arise in communication and escalation of problems (yes, it’s not uncommon). And this is where an external company will have the most difficulties, because information security processes must be seamlessly integrated into the software development life cycle, which is organizationally and technically arranged differently in each company, with its own nuances and peculiarities.
Next, costs. This approach is the least expensive in terms of human and technical resources, but pay in money will have a lot. After all, a company that will do absolutely everything, and will cost accordingly – the team on the project is allocated a large (about 5-10 people, ie from 30 000 to 42 000 CAD monthly, and this in turn, about 495,000 CAD per year – only on direct labor costs), the services themselves due to their uniqueness are also worth a lot (hardly less than 30 – 50 thousand CAD per month, ie even plus-minus C $ 620,000 per year) plus associated costs (meetings, business trips, processing, etc.). The process takes more than one month (over four, and can last up to a year), so that all this will cost several hundred thousand Canadian dollars.
It turns out that it is unlikely to completely outsource the secure development process, even in a large company, and it is better not to do this if you want to build a truly working and efficient implementation. Those with experience in such outsourcing projects most often dissuade businesses from them.
It’s worth looking at another option. To which we will now turn.
Approach 2: The process is completely in-house
So you’ve decided to build the entire process entirely in-house. This may indeed seem logical. In-house specialists who are familiar both with the processes inside the company and with the toolstack of technologies used in development, can implement the secure development process much faster and more efficiently. After all, they don’t need to explain how to fill out requests, by what rules development lives, who to escalate problems to if something happens and other things. Everything seems to be fine, what can go wrong? And the devil, as usual, lies in the details.
The main problem has already been mentioned – the specialists. There are few of them, especially those who are looking for or want to change jobs. They are expensive enough, but how many of them are needed to implement the necessary project in, say, a medium-sized company with 500 developers? At a minimum, you need a line manager who understands the goal, who has a complete vision of the finished process, how it should look and what it should be. And at least a few people for each major area within the process, and there are at least seven at the very beginning of the journey:
- Static analysis (SAST);
- Dynamic analysis (DAST);
- Open source component analysis (OSA/SCA);
- Mobile application analysis (MAST);
- Container analysis (CA);
- Tool integration (conditionally DevOps);
- Server administration and keeping tools up to date.
And that’s really just for starters, when we’re plugging in the first teams. Why so many people, you may ask? It’s very simple: the minimum range of work at the beginning, in order to launch the process properly, is enormous. First of all, it is to understand and describe the strategy of the safe development process, which is the basis for everything. It is it that will provide the basics of the processes, lists of tools and justification for budget planning.
Another important layer is describing the initial business processes for each practice, drawing up the requirements for the tools that will be piloted, and directly selecting, initially setting up and operating them. The next significant step is not to drown in the number of triggers from the tools, which must necessarily be parsed, transferred to the development teams, and then to control the correctness of the corrections, once the teams start to drive into the process. All this takes time, people and resources. And it’s often very difficult to get such a large team together at once.
And you have to understand that if you’re doing everything yourself from scratch, it can also take quite a lot of time, even more than if you’re outsourcing. There are a lot of examples of such projects where it took about 2-3 years to launch the three main practices (SAST, SCA, DAST) and a lot of work and effort.
Summing up, we note that the human and technical resources here occupy the main place, in contrast to the first approach, because all the work is entirely on the shoulders of staff and available tools. In terms of financial inputs, this approach is less expensive than the previous one, if we compare the first year, because in fact the main costs are the salaries of employees. Here you can try not to go beyond 1.5 million a month, which will give 30-35 thousand CAD a year.
However, in three years (if that much will be spent on DevSecOps implementation) this expense item may take at least C$1,500,000, as the team will grow and develop, and then the total cost will be even higher than for a year of outsourcing. However, your trained super-team will stay with you to maintain the secure development process, you won’t need to call in outside experts again and again. In addition, over time, you can start offering outsourced experts yourself, nurturing the specialists internally. And so cover a significant part of the costs.
So, here too there are pros and cons, so where is the perfect balance? And it is, as always, somewhere in the middle. And below we will consider a combination of the first and second approaches, in the hope to collect more pros and get rid of cons.
Approach 3: Combined
So, we need to collect all the pros and not make any bumps, right? Then we take and combine everything in the right proportion. How’s that?
The point of the proposed approach is that, on the one hand, do not refuse to help outside companies that have extensive experience in implementing such projects, but in no case forget about the internal component and your own competence. Yes, no matter how obvious it may sound, but still you can’t do without an internal driver and own specialists, it is an integral part of the successful process. Let’s see how everything can be organized.
Within the company, there is an understanding and desire to implement a secure development process. To begin with, it should be headed by someone from the organization who understands (at least in general terms) what is needed to get out of the process. At this stage, an external company together with an internal driver will help define more precisely the goals and objectives of the project, describe the concept, the top-level business processes. A plan will also be made to hire people to the team (both forming from scratch and expanding the current team, if it already exists). Symbiosis here is very important, because you need to combine experience, an ideal model from best practices with the real life of the organization. After that, the internal and external teams together begin the step-by-step implementation of the secure development process, in which the external company, as the bearer of “sacred” knowledge, generously shares it with the internal team, teaching them the various nuances and intricacies of the process.
The ideal in this case is for the company to help from outside in the implementation, training employees, gradually building up their competencies. In other words, the ideal form of interaction is mentoring. The internal team trains in combat conditions, the external team guides, corrects, advises. In rare cases, if something does not work at all, the gurus can transfer the tasks completely to themselves. And then, when the process is established, the transition should be made to a support format, when external people are involved “on the pick-up” when their own forces are insufficient. For example, to deal with technical debt, customization of tools, in general, for point tasks that require a lot of time and resources.
Yes, not all the outside companies are ready to give their knowledge and competence to the customer, because it is much more profitable to hold everything in their hands and “steer” the process, but, as a rule, it is possible to come to an agreement.
And now about resources. This approach is balanced not only in description but also in terms of costs. After all, all items are divided between the internal and external teams, which means that time, budget and human resources can be distributed more smoothly. To be more specific, the startup and startup time for the combined process is quite low, the whole project may take about a year and a half, the cash costs are shared between teams, which means that the payroll and external company costs will be less (it is possible to do with the total project costs of 600 to 800 thousand Canadian dollars).
To conclude the article
Of course, each organization decides for itself which way to choose, everything is thoroughly studied. Nevertheless, the combined approach here is the most advantageous, because it not only allows to balance the resources and time, but also to extract the maximum benefit. After all, if this option is implemented, both the team and its competence will grow in the process. And this is one of the most valuable resources a software development organization can have. And then, of course, the transition to DevSecOps can be limited in time, but in general, you cannot suddenly stop dealing with security when creating software. The interaction and mutual development of these two areas is an integral part of a successful business.
One hacker can do as much damage as 10,000 soldiers!
