Every security vendor, movie or series likes to talk about detecting a zero-day event or detecting sophisticated attackers, but the incident reality is very different. Most security incidents occur not because of a new vulnerability or threat but due to the lack of prioritization of security within development and the company’s culture.
You can have great security policies, training and processes, but their impact will be blunted if the controls in place are seen as a tax on productivity or business agility. In the existing ‘tax’ model, each security control requirement is weighed based on the risk to the company or its customers if it is or is not properly implemented. Though helpful, it sets a defensive precedent that proper security comes at a cost.
But what if we changed the defensive mindset to an offensive one? What if, instead, we changed the culture when it comes to viewing security and the employee’s role in it as an asset?
The first step in this offensive reset is acknowledging the defensive strategy failures:
1. Policies are accepted and video training taken by rote, but they aren’t actionable: We only realize that policies aren’t well understood once an incident occurs. The feedback given when an employee is non-compliant is: ‘I accepted and took the training, but I thought in this instance, since it was a SaaS marketing application, it didn’t need to go through the vendor process.’
2. Easy to fail and impossible to succeed: Developers are told that something is not compliant, but they don’t understand why it matters. The feedback a security operations team will likely receive from engineering or other line of business is that they are paid to deliver a product, so why does it matter if they don’t apply NIST 800-53 best practices? What is that anyway? Besides, no one has remote access to the server.
3. Responsibility and no tooling: We give data and system owners the responsibility to hold their teams accountable for following policy. However, the assumption is that there is a baseline in the era of cloud when often, there is not, and the team learns the hard way after an incident. The feedback given to the response team is often that the cloud provider service is PCI compliant, and the team used their provided template in the way they thought was correct.
The next step is to address the issue by changing to an offensive paradigm and assuming that your employees want to do the right thing while remembering it’s our job to enable them to be successful:
1. Make training contextually relevant: We must accept that developers are not trained in security coding and OWASP top 10 testing alerts. Instead of beating them over the head, we should invest in quality application code training that teaches them about web application stacks – how to exploit OWASP top 10 vulnerabilities and mitigate them. Once they have these new skills, empower and reward them for reviewing and improving software code and internal systems. Developers and engineers like to build things and solve problems, so let’s unlock that power.
2. Create security guard rails for the cloud: Just as we have always done for asset baselines, we should work to provide our development and lines of businesses with blueprints to start with risk baselines accounts. These blueprints have security baked in to properly restrict ingress, egress and access rights. Even if your organization isn’t starting off clean, you can always collaborate with teams to roadmap these into place. The key is ‘giving’ them an answer and not just notification of failure.
3. Share responsibility for security controls: When audits are performed, the requirements and evidence collected are usually completed by the security and compliance team. Instead, involve the business units in that process to better understand the requirements and help ensure that the controls are implemented and evidence is available for audit collection.
How do you successfully complete a SOC2 audit within two months? You do it through active collaboration and cross-functional teams while ensuring separation of duties and allowing security to be embedded throughout the organization. Changing security from a defensive tax model to an offensive model does not change overnight, but with the proper steps in place, teams will be enabled to succeed.