Discovering Security Champions

I recently attended a webcast from Carnegie Mellon University entitled "At What Point Does DevSecOps Become Too Risky for the Business?" (I’m not sure if this was the appropriate title, but I don’t pretend to criticize that). This webcast was presented by Hasan Yasar, Technical Director at Software Engineering Institute at Carnegie Mellon, and Altaz Valani, Director of Research at Security Compass. When I watched it, I found some similarities with the information that I shared in a post on DevSecOps/SecDevOps. However, these authors spoke on a broader sense, considering the business risks of companies offering software. I want to recap some of their ideas, grouped here into five general recommendations, and expand a little on another one (a sixth recommendation): the Security Champions. This last section is supported by a SAFECode.org paper called "Software Security Takes a Champion," in which Altaz Valani also participated.

Many companies reflect an urgency for the rapid deployment of new features in their apps without considering security. Is software security being omitted because it's assumed to be an obstacle? And in a broader context, what about business security? Is business risk management being ignored? Within the SecDevOps culture, it's expected that both speed and security are included from the beginning. Don't start building and deploying apps continuously from your company if you haven't assessed the business risks and how they can be avoided.

Companies can manage risk from different perspectives. For example, the "cyber-resiliency perspective" and the "compliance perspective." In the former, considering possible impacts due to future vulnerabilities being attacked, the main concern is to find rapid solutions to those problems every time. In the latter, usually from a highly regulated environment, more thought is given to the evaluation of compliance with rules. It’s recommended to work from this compliance perspective and set requirements based on public security standards such as GDPR, HIPAA, and PCI DSS from the beginning (see our compilation called Criteria). These requirements must be adjusted to the structure and functionality of the software developed in your business. Besides, some must mean translating your business risks to technical language.

The security requirements may indeed be in constant remodeling. But be aware that if you define requirements to be met in your company, which can be re-evaluated, the idea is that they should be obligatory. If at any point they haven’t been met, then any workflow before the software deployment must be stopped. Later, you should ask questions such as: Did the developer not understand something? Do they need training? Is it a false positive by the tool? Is this an appropriate tool? Also, ensure that reports of non-compliance reach each interested audience in a language suitable for their understanding.

Maintaining secure infrastructures and products is a challenge, especially when there are constant changes in their architecture. Therefore, security testing must also be continuous. Automation in processes such as SAST and DAST will depend on some tools; you must be careful with your use of them. It’s not a question of acquiring tools because they’re offered as new, or because the competition uses this and that, or because they are supposed to be useful in your security testing processes. "What tools are essential for our business?" This is a question you can answer with the help of your developers with security expertise (Security Champions?).

What is highly recommended in approaches such as SecDevOps is the integration of groups. With security already in place, besides a 'technical approach' from software engineering, it should have a 'business approach' from business risk management. Therefore, it’s recommended to include the business group in SecDevOps with its security viewpoint. With this, it’s expected that the mindset of many will change towards the framework in which security is seen as indispensable for the maintenance of production and income generation. It’s important to emphasize that the information to be transferred between groups must be clear and complete. On the one hand, the developers of your company must understand whether or not their work is contributing to managing business risks. On the other hand, those in charge of your business' security must understand what the technical team is communicating to them (e.g., challenges, issues, needs).

The integration of teams can be favored by the presence of 'champions' of each area. In the inclusion of security in software engineering for business, having one or more 'Security Champions' (SC) can be quite useful.

In short, the SC is a software developer who possesses and applies extensive security knowledge within a development team. The SC is responsible for identifying and solving security problems early in the SDLC so as not to slow down processes. The SC assists with verification that security requirements are met during the development process. Additionally, they translate technical information from the DevOps group to the security and business management groups, and vice versa. Therefore, the SC interacts closely with these groups, gets along with the experts on each side, and builds a bridge between them.

The SC can prioritize security issues based on business risks, of which she has a full understanding. She also assists in the selection and use of assessment tools and the interpretation of results. As an outcome of education at universities, there are usually few security-educated software engineers with extensive knowledge of "both internal and customer-related security (and regulatory) needs." With SC’s help, a formal, contextualized, and well-defined support for the security training of developers and other members can be established within a company. The SC can conduct activities with the developers to expand their knowledge and motivate them to become security experts. Also, the SC can help ensure that members of a company’s security team are no longer seen as 'bad cops' and that developers don’t see them as adversaries to avoid.

First of all, the SC should be a person with knowledge of software engineering. Especially about tools and methods for the development and deployment of secure software. This person should know about threat identification and mitigation, risk analysis, and attack path analysis. Also, this individual should know the multiplicity of existing vulnerabilities, the lists that group them, and how they’re classified (quite exciting topics that we hope to review soon). They should have skills in the discussion and presentation of information. And finally, the SC should be able to resolve conflicts, motivate people, and be kind and attentive to others.

Companies that develop and offer software as a product or service may employ different strategies to become part of a culture in which security plays an essential role. It’s one thing for these companies to have paid tools and services for their protection. It’s undoubtedly another thing to have developers in their staff who, without being forced, want to acquire and apply security knowledge. Among them, possibly, there will be emerging Security Champions, who will certainly bring them significant benefits.

So, have you already discovered at least one SC among your team members?