/filters:no_upscale()/sponsorship/topic/842bff58-a0cf-4c4d-ae49-da385bfe4c22/AkkaLogoRSB-1719307236177.png)
The majority of successful attacks on organizations exploit software vulnerabilities and backdoors. Fortunately, software vulnerability scanners are no longer considered to be exotic by companies. Instead, they have become a core element of security infrastructure. With a small scope of development work, you can use a scanner manually. However, a larger amount of code calls for automated scanning. But who should manage it? Who should decide how often to check releases, verify vulnerabilities, reject a release, and manage the fixing of code vulnerabilities, as well as answer any other related questions? This is where an Application Security Manager (ASM) comes to the fore.
But how can you find such a unique person or foster them in-house? This article describes the requirements for an ASM based on software development practices in companies.
Sooner or later, organizations realize the need to hire such a person, especially when they lack in-house specialists capable of performing the role. What about developers? Although experienced in software development per se, they can hardly translate detected vulnerabilities into information security or business risks. Why not take a security officer? Deep diving into the finest details of development is a challenge for them. However, verifying vulnerabilities requires understanding codes in different languages and, therefore, serious development experience.
Build, Operate, and Secure Distributed Applications. Learn More.
Let’s see what tasks arise during the secure development process that an ASM has to solve.
You may think that an ASM just checks code for security compliance, but security issues arise at various system lifecycle stages, from design to release for production. There are various models for building a secure development lifecycle (Software Security Touchpoints, SDLC, etc.) and different adoption methods (waterfall, agile), depending on the approach used. However, they all agree on key points: you need to keep security in mind at all system lifecycle stages.
Obviously, with a relatively large project, it’s unlikely that a single person will be able to perform all aspects of such a role. It’s very rare to find a single person that can develop app security requirements, review app architecture, verify the work of analysts, and assess code security. Other challenges include making sure the app has undergone all required security tests and that the system has been securely deployed and correctly configured.
Moreover, these activities are often performed by different teams and business units. To make it all work, the ASM should become the driving force of the overall process. Such a manager as this has to ensure compliance with secure development practices either on their own or by delegating certain tasks to narrow specialists. However, our experience shows that an ASM can’t simply assign tasks to the relevant personnel and then wait for results.
First, an ASM has to understand what a supervised project is about. This is especially important for agile development, where, unlike the waterfall model, you don’t have two months to perform a pre-release review. An АSМ’s job is to make sure that the requirements set at the design stage are correctly interpreted by the team, properly adopted in the architecture, are generally feasible, and will not cause serious technical problems in the future. Typically, the ASM is the main person who reads, interprets, and assesses automated reports and third-party audits. It’s also the responsibility of the ASM to filter out irrelevant and incorrect results, assess risks, and participate in managing exceptions and developing mitigation measures.
Here’s a real-life example: a source code scanning or assessment has revealed an insecure hash function (MD5). The company’s policy prohibits the use of MD5, and the vendor agrees to replace it with a more secure function within three months at a high cost. However, in this case, the hash function intolerance to collisions didn’t affect system security at all, since the function was not used to protect integrity. Here, a formal approach and function replacement slowed down release to production and cost a fortune, without any serious justification or security gain.
Second, an ASM should know about various domains, including development processes and information security principles. Hard skills are also important because it’s very difficult to assess the results provided by narrow specialists and automated tools if you can’t read the code and don’t understand how vulnerabilities can be exploited. When a code analysis or penetration test reveals a critical vulnerability, it’s quite common for developers (who are also committed to creating a secure system) to not accept the results and claim that auditors failed to exploit the vulnerability. How to tell who is right here? Indeed, resolving such a dispute in an unbiased manner requires technical skills. If the secure software development process is outsourced and/or provided as a service, how will someone check that "technical" practices are OK, and who will that be?
Another real-life example: a new development tool is being introduced and its efficiency is tested on a reference project, whereupon it’s put to production use. Projects are successively connected, a visual green dashboard is drawn and then a security incident occurs. It turns out that the exploited backdoor should have been discovered as early as the dynamic analysis stage. But this didn’t happen because nobody checked how this high-end vulnerability scanner, which usually provides excellent results, works with SPA applications on the new JavaScript framework. It turned out that the scanner failed to "see" the dynamically generated authentication form and perform the necessary checks. However, nobody noticed this because everything else worked properly. Developers didn’t need to dive into specific features of scanner operation to notice the vulnerability, while security officers didn’t see critical differences between web development approaches.
Anyone who has studied the market has likely faced an acute shortage of application security specialists. Typically, the scenario looks like this: internal customers set requirements for the candidate and forward them to HR. If the requirements are strict, then a free search returns no results, since seasoned specialists very rarely post their CVs in the public domain. When searching for a new job, they can easily find opportunities through existing contacts. So, what to do?
You can try to solicit a professional from other companies, but this isn’t always acceptable for various reasons. More and more often, ASM outstaffing contests are conducted on the market, allowing you to successfully solve the issue by using experts from a service provider.
Yet, there is another option. You can try to develop your own ASM in-house from either:
Both types of candidates will need to master the areas where they lack knowledge. Candidates with a developer background will have a better understanding of the prevailing culture and processes from the teams they have worked on. However, it can take them quite a long time to master knowledge domains related to information security. Experience shows that people who are interested in information security and already have a certain level of knowledge in application security can be found among developers, testers, analysts, and architects. Consequently, they can be ideal candidates for the ASM position.
On the other hand, security professionals will have to adapt by changing their traditional approaches and adopting the development team culture. However, if a security specialist is experienced in coding and familiar with development processes, they should be able to join the team quickly and smoothly.
Secure development is, first of all, a business process requiring the cohesive performance of all team members. A qualified ASM is a key driver of this process, as well as an inspirer, team leader, performer, and supervisor -- essentially a jack-of-all-trades. While finding or developing such a specialist isn’t easy, the business benefits of securing the ideal candidate can be profound.
Daniil Chernov, DerScanner CTO, MSIS, CISSP, CISA, has a 15+ year experience in cybersecurity. In 2005 – 2007 he worked as an Information Security analyst in Informzaschita, and till 2015 held different positions in Jet Infosystems system integrator. In 2015 Daniil Chernov took up a position as a CTO of DerScanner project, binary SAST solution. He regularly holds appsec webinars and writes pieces about secure development for the trade press.
