A common security issue I see is that Security Teams simply have trouble getting traction. That is, they do all kinds of analysis and testing, but development teams never directly address the changes that need to be made.
Some may be aware of their need for security but may not understand the role of a Security Team. A Security Department does not typically configure servers, network equipment, or contribute product code. Also, Security Team members may not comprehend that Security does not typically make business decisions.
As some have experienced, saying that security is everyone’s job can only have a limited effect, even with full cooperation of the whole business. A much more effective situation is if Security has been strategically integrated with the culture.
Strategy
Deciding the relationship between Software Engineering and Application Security clearly and according to the desired culture will make it easier to be embraced by the culture. This should be done as early as possible and communicated up-front during employee onboarding right beside the message that ‘Security is everyone’s job’.
Application Security should strive to supply information that is readily available for Product and Architecture to make decisions. They should strive to supply guidelines and tooling for Governance of the Development process. They should also ensure the production security posture is known to the stakeholders and Development itself.
In many organizations, Security members do not contribute code to the product. On the surface, being a non-conde-contributing team can keep the compliance lines clear for things like Separation of Concerns. I have seen organizations where any member is allowed to contribute code. This can build a strong developer centric culture, but it also requires a strong process with proper pre-merge reviews and tooling in place to ensure compliance with policies, standards, and guidelines.
Some organizations will recognize that Security Professionals will need to be highly trained in Security and that Application Security is a specialization requiring a significant investment of ongoing learning. Also, Application Security for a software developing organization is a further specialization of that. It is also closely related to Quality as an Assurance practice. AppSec Engineers will usually not be Software Engineering experts, nor Software Architects because of the broad experience and training already required of them. Therefore, they should not be making specific Software Engineering or Software Architectural decisions, although they bring strong supporting expertise and data.
Effective
Being clear about who is responsible for designing and implementing can have several effects that you should be aware of. Firstly, some Security people have fallen prey to the fallacy that the only way to effectively make change is for Security to ride roughshod over programmers. Explicitly placing authority for change in the more qualified hands of Sofware Engineers will frustrate some individuals in Security.
If you have experienced the situation where Security rides roughshod over programmers you have seen how it makes Security a disruption because it shortcuts any established processes and best practices including sidestepping Product, Architecture and often any sort of Engineering Design. As many of us know, disruption is the primary enemy of every coder. In such a situation it makes Security a willful enemy of progress.
On the positive side, explaining this early can allow those with inexperience to observe how the process works to get things done. They will also see how they are relieved of the stress of responsibility when they do not agree with the action or lack of action taken as the communication and risk acceptance can be traced through the process to be carried on many shoulders. This then builds on the fellowship of the team cooperation over time and gives both Security and Development the opportunity to appreciate the strength of each other’s craft.
Once this is established, when a Security Incident happens, “breaking glass” is much more effective because of clear roles and trust among the teams. The long-term effect is then also established as the result of the emergency can have a known path back into the process and has less of a chance of regressing in the future.
Takeaway
Having a security culture beyond ‘Security is Everyone’s Job’ requires the recognition of the strengths each part of the organization brings. A process established on this recognition will feel natural, despite the very deliberate efforts to get it there.
The Code Snob 