Cybersecurity compliance training for developers – From security awareness to security by design
Márk Félegyházi (CEO, Avatao)
Compliance standards are a valuable but mostly misunderstood part of the corporate culture. Like any other certificate, a compliance certificate demonstrates that the entity/business operates according to a commonly accepted standard and signals trust towards third parties. A successful compliance certificate eases regulatory processes, opens new markets, and in general speeds up revenue generation, which is the key metric for businesses.
Yet, very often this key business objective does not permeate the company culture as it does not align with the individual goals of stakeholders. In particular, the important control of cybersecurity compliance training is considered as a pain in the neck, a “must do” activity that is like a bitter pill one needs to swallow to get better. This has several root causes that I discuss below.
Core assumptions about cybersecurity compliance training
There are some fundamental misconceptions between the ones who own compliance training and those who need to take it. Because of that, compliance training has garnered a bad reputation over time among people.
1. Compliance training is boring:
Compliance training is something one has to do. It is forced on the people and usually boring. The main goal and behavior for people is to just get over it as soon and as painless as possible
2. Compliance training is useless:
People often believe that compliance training does not contribute to the work objectives and hence it is net time wasted.
3. Compliance training is an obstacle:
Following the previous prejudice, people consider compliance training as a waste of time that takes away precious resources to achieve their real goals. In the case of developers, this compliance training slows them down to ship awesome code.
4. Compliance training needs to be hated:
Anything that derails or slows down people from reaching their objective is the target of bickering and complaining among teams. In the worst case, individuals and teams sabotage the mandatory training jeopardizing the core business goal of achieving a trust certificate.
Let’s face it, most of the compliance trainings deserve their bad reputation. This is due to the difficult and misaligned incentives between the stakeholders sponsoring and delivering the training versus the daily workflow and objectives of the people taking the training. Let’s now have a look at what could potentially go wrong.
Major pitfalls in delivering cybersecurity compliance training for developers
1. Introducing compliance without context
Compliance training is usually pushed onto the people without giving it a reason d’etre. People are told to do it, but the context is not explained to them. Developers for example do not necessarily understand why solving a few OWASP top 10 exercises, a classic first step in compliance would make them a better coder. They definitely do not comprehend the value they deliver to the company when they fulfill their compliance training requirements.
2. Not aligning compliance goals with team and individual goals
Delivering cybersecurity compliance training is haunted by the misaligned incentives between the business leaders and the people taking the training. Obviously, business leaders advocate that the compliance risk be decreased by sound cybersecurity processes and compliance training. Yet, they must communicate this to developer teams and facilitate incorporating cybersecurity into their product delivery goals. Otherwise, developers keep their main objective of shipping code fast in mind and put less priority on making a product secure by design.
3. Using outdated, boring learning modalities
Even if compliance training is mandated, or especially when it is mandated, it has to relate closely to the daily job and workflow of developers. Explainer videos with quizzes or click-through training alienate developers from the exciting topic of cybersecurity.
4. Delivering the minimum training
Counterintuitively, delivering a minimum training once a year gives the message that secure coding is not important and decreases the value in the eyes of developers. Without the vision of implementing security by design throughout the whole software development lifecycle (SDLC), secure coding compliance training remains a nuisance for developers.
Compliance training for developers delivered right
My arguments above hopefully made you question some of the fundamentally flawed assumptions about cybersecurity compliance training. The bottom line is that standalone secure coding training for compliance is only scratching the surface and likely encounters significant resistance from developers. Many of our customers who do not implement compliance training as part of an overarching security program realize that adoption is slow and developers try to slack.
So how can you win this uphill battle? Can developers be involved in compliance and security awareness training? Here are a few thoughts that can move the needle towards achieving more adoption.
1. Align the goals of people and leaders
Security must be a priority from the very beginning and it has to be included in the business goals when building the whole engineering culture. The era of “move fast and break things is over”. Today’s software products affect critical areas in life and hence need to be built with security in mind. Security must be a feature developers care about when delivering the product. Developers must be recognized for building secure products vs. appraising a hacker culture where breakers are heroes. Developers need to understand the business value the compliance certificate delivers to their company, expressed in hard currency. They also need to see how their actions affect compliance and thus the overall trust profile of the company.
2. Recognize people for their effort
Compliance certificates demonstrate that the business is trustworthy, and similarly individual security certificates demonstrate that the people are trustworthy. There should be a connection between the compliance result of the company and the achievements of people. How about designing a PCI DSS or SOC 2 certificate for individuals that is directly linked to their role and contribution to the company compliance pass? Instead of vanity certificates that are obtained by preparing for tricky and long MCQ quizzes, we could have proper application security certificates that recognize hands-on, applicable knowledge, and the contribution to real achievements, like a company passing a compliance certification.
3. Allow time to build well
Abraham Lincoln said, “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Modern software development teams seem to forget this and sacrifice everything at the altar of continuous deadlines. As a manager, put time on your team’s calendar to sharpen their axe. This is a fundamental mindset that allows developers to be more efficient and incorporate security by design into their workflow.
4. Deliver relevant training content
It is particularly important to deliver relevant training content. When developers take time to learn, they want to see real-life, hands-on scenarios that have immediate takeaways to their jobs. Next-next-finish trainings and advanced multiple-choice questions do not reflect much learning to their daily life and feel out-of-context. Our Avatao team fundamentally believes in this mission and trusts developers to learn from hands-on scenarios. We think that enumerating common vulnerabilities and giving the “hacker’s mindset” to developers is not enough. We should praise developers for building robust, reliable code.
5. Do or do not, there is no try
Delivering substandard, sporadic, and weak security training is counterproductive. I am deeply convinced that fulfilling minimal compliance requirements without putting security compliance training for developers into a fully-developed learning journey only increases the resistance of developers towards security. There should be no security compliance or security awareness training for developers. There should be a coding journey for developers, step-by-step, skill level-by-level that leans on security as a core principle and leads them towards delivering awesome products. Compliance must be a side-effect of this journey, not the ultimate goal.
Avatao has a core mission of delivering this secure coding journey for every developer. What are you waiting for? Become a secure developer yourself.
Reading Time: 6 minutes For most companies, security is considered a side quest, which is partly related to the daily processes. In reality, security ought to be a strong foundation of any organization. To ensure the defense of the enterprise, the relevant teams need strong security knowledge and abilities.
Reading Time: 6 minutes To build an enterprise security program, one has to go back to the well-known fundamentals of organizational change: People, Process, and Technology (originates from Harold Leavitt’s “Applied Organization Change in Industry”, 1964).
Reading Time: 8 minutes If you are working on Java projects you might have heard about other languages that run on the JVM, like Clojure, Kotlin, or Scala. Programmers like to try new things out but is it worth it to pick one of them over Java?