Discovering Security ChampionsSix recommendations for SecDevOps from Carnegie Mellon
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 that I wrote a while ago. However, these authors spoke on a broader spectrum, 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 (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.
1. Insert security into your processes asap.
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?
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.
2. Set security requirements from the beginning.
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 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
from the beginning (see our compilation called 'Rules').
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.
3. Keep the security requirements as obligatory.
The security requirements may indeed be in constant remodeling. But be clear 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? Does he 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.
4. Use the right tools for your business.
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
DAST will depend on some tools;
you must be careful concerning 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?).
5. Look at security from technical and business perspectives.
What is highly recommended in approaches such as
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
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).
'Security Champions' (a sixth recommendation)
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.
What is a Security Champion, and what does he do?
In short, the
SC is a software developer
who possesses and applies extensive security knowledge
within a development team.
SC is responsible for identifying and solving security problems early
SDLC so as not to slow down processes.
SC assists with verification that security requirements are met
during the development process.
Additionally, he translates technical information from the
to the security and business management groups, and vice versa.
SC interacts closely with these groups,
gets along with the experts on each side, and builds a bridge between them.
SC can prioritize security issues based on business risks,
of which he has a full understanding.
He 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."
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.
SC can conduct activities with the developers
to expand their knowledge and motivate them to become security experts.
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.
What knowledge should the SC possess?
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).
He 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?