A recent article about DevSecOps tools may have you thinking about what sets security apart from other disciplines within the software production space. As the rise of DeSecOps presented a new approach to security — complete with its own set of tools and quirps — it did something else, too. It cemented security’s status as a “specialty” discipline, at the fingertips of only a select few, and far removed from the reach of all employees in an organisation.
But what if, rather than thinking of security as a labour for “security officers”, you were to think of it as an arch discipline that could and should be touched by multiple employees across a wide range of roles and titles? What if all employees in an organisation were security ambassadors who bore the responsibility and the right to implement security guidelines?
The first thing that would happen if you were to adopt such a security-for-all mindset is you’d likely end up with security that is tightly integrated into development cycles and developers who were actively involved in the creation of secure software.
Secondly, you’d find yourself dealing with security that enters the SDLC in any and every stage. This goes beyond the placement of security into DevOps, and speaks directly to the presence of security in every corner of an organisation, with the assumption that even if security doesn't directly affect your job it doesn’t exempt you from caring about it.
Security is everyone’s responsibility
An article by Adrian Sanabria about the psychology of security, where he likened application security to security standards in the retail industry, is a good place to start thinking about inclusive security standards.
In that article he explains, rather beautifully, that the solution to shoplifting cannot be placing more security officers to follow shoppers around, but rather the solution is sure to come from making all employees in the store —whether the designated security officer or the clerk, the kid who stocks the shelves or the one who bags the groceries —security minded individuals who understand their role in preventing shoplifting as pertinently as they understand their role in growing the retailer's profit.
To follow up on Sanabria’s metaphor, if you want to put security into the minds of all employees, making room for it in DevOps could be one place to start. Another would be revisiting the people-process-tools equation and to think about the weight given to the people in it. The “other” employees, those that are not security professionals, could be a tremendous asset to security efforts and may well be what prevents security teams from burning out from the overflow of alerts that flood them.
Simply, getting more employees involved in security efforts at all stages of the SDLC will both take the load off security teams and will turn other employees in an organisation into security professionals, too.
Doesn’t ‘security-for-all’ make security teams redundant?
Not in the least. If we had mentioned above the pitfalls of hoarding security responsibilities to security “specialists” only, and exempting other workers from being security-minded professionals, then the question that follows is “what will be the purpose of dedicated security teams if all employees where theoretically responsible for security?”
Security teams are the leaders of the pack. It’s that simple. It is ultimately on them to oversee all security related aspects in the organisation and to make sure that security issues are handled by other employees in different departments. Security officers may be responsible for setting up security policies and integrating them into the company’s workflow. Security teams may decide on the types of alerts that will pop up on developers’ screens and the chain of command for their resolution.
In most companies security is a generalist term encompassing all forms of security for all products and services given by the company. Unless you are an enterprise level organisation and have a huge security workforce, your security team is likely responsible for anything security-related on any level, with no distinction between expertise or subsets of knowledge.
Being responsible for everything — from access control to policies, access codes and passwords, and training new employees not to click on suspicious emails —saturates security teams with work they simply cannot get to. Beyond overwhelming them, these alerts are better handled by dedicated personnel specifically knowledgeable in certain fields.
Let’s take code creation for example. 60 per cent to 80 per cent of modern day applications rely on open source code. This makes most developers working in application building naturally versed in open source usage. Expecting security teams to remediate security issues in open source code is essentially asking people that don’t have the tools to accomplish the job to do it anyway. Conversely, asking developers to attend to the security alerts generated by software composition analysis tools (SCA) brings the problem to the doorstep of those who have the training to fix it. Security teams, in other words, don’t know how developers choose open source components, nor are they familiar with patching techniques, reconfiguring or version updating.
Products alone won’t do the trick
The single most common mistake companies make when they decide to up their security awareness is to throw more tools at the problem. However, products alone won’t improve security. Unless they come with a security culture in tow, security tools will simply add more alerts and flag more issues, overwhelming your security team even further.
A security culture starts with the understanding that security is not a static entity but a living, “breathing” organism that changes constantly. Vulnerabilities are found daily, and security issues need to be attended to immediately if a company is to beat hackers looking to exploit. Code changes, servers, clients and communities shift, and new equipment and dependencies are constantly added on to products. All these need constant nurturing.
Once the understanding of how security works is in place, what follows is that periodic security testing is simply not an option. Security needs to be an ongoing process — a constant one — only achievable through automation.
New security culture in bloom
A security culture fit for our times combines the application of automatic tools to shore up vulnerabilities in real-time and the security manpower to attend to the alerts that come up.
Such a culture understands that security teams are necessary yet can’t do the job alone. Security efforts require a company wide, hands-on approach to security throughout all stages of the SDLC.
Ultimately stopping attacks and breaches should be a joint objective for everyone in the company, just like increasing revenue.
Rami Sass, CEO and Co-Founder, WhiteSource
Image Credit: Wright Studio / Shutterstock