Reading Time: 6 minutes
5 key challenges when building a security training program

By Márk Félegyházi (Avatao CEO)

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). Any successful strategy focuses on transforming these three areas, yet different leaders focus their efforts on one or the other.
In this blog, we advocate that transforming the People Operations is the most difficult yet the most rewarding area of the three basic pillars of the enterprise security program. Still, due to the difficulty to express results and the potential long feedback cycle of benefits, most leaders and managers tackle the problems backward, starting with Technology and work towards People.

The first line of defense

People will always be the primary source of errors and vulnerabilities but they are also the first line of defense against cybersecurity threats. Even with the most sophisticated technology in place, it was always the great people who discovered that something went wrong (ex FireEye and SolarWinds attack).

Traditionally, security was thought to be the job of the security team. A well-rounded enterprise security program, however, should extend this responsibility to each employee to some extent. More and more businesses depend on the security and correct operation of their software products and hence secure coding training for developers becomes an essential part of a solid enterprise security program.

      The most common challenges businesses may face

      Building a security program has never been an easy and straightforward task. There is a great number of factors to be considered in the process. Sometimes it seems like an unnecessary struggle, but the outcome always proves the opposite. On your way towards a well-built security program, you may meet several challenges. We collected the most common ones for you.

        1. Developers care about speed

        Let’s face it: The main objective of software developers is to ship code as fast as possible without breaking the whole product. Developers care about committing the features to production that makes the most short-term impact on users.
        Yet, by now most developers understood that software development is not a sprint but a marathon where you build up a product step-by-step. Hasty planning and hurry to ship code in a few sprints can cause the accumulation of technical and security debt. This might not hurt in the short run, but eventually, any product will collapse under scale and pressure when it was built on weak foundations. For most developers, this process and the effects are clear in case of testing or code optimization, but not in security.

          2. Developers lack security education and training

          The importance of testing is now part of every computer science curriculum. Unit tests, integration tests, and TDD, in general, became commonly accepted best practices for high-quality software development. The same is not true for secure coding training for CS students. Cybersecurity is still a missing part of the computer science curricula in most universities worldwide.

            3. Security training is considered a necessary evil

            Training, especially company-driven training, is one of those activities where the feedback and results show up with a significant delay. Very few people are dedicated enough to improve their skills consistently and systematically day-by-day. Most developers believe that on-the-job experience will lead them forward. Organized training by companies is considered a pain and a necessary evil that drives them away from their daily job.

              4. Security is a gateway function that blocks modern DevOps processes

              Security is traditionally considered as an obstacle that hinders people from doing their job. Like the early days, seatbelts were considered a bad thing as they limited people in their free movement while driving. Similarly, developers often consider visible guardrails and tools of security useless cycles of programming that prevents them from going with full speed in shipping products.

                5. Misalignment of responsibilities

                Many developers have a strong sense of responsibility towards their code, but some developers simply do not care if their code is high-quality or not. If the processes allow them to slack, these developers will sacrifice long-term stability for short-term speed. Since most developers are not directly responsible for the mistakes they make, they might optimize for speed, not quality.

                  Conclusion

                  Awareness of the importance of security training is on the rise, but it still has a long way to go. It is often considered as a setback that slows down the workflow, but as mentioned earlier, the positive effects of security training in the long term are indisputable. Just like any process related to products and services, security needs a strong base to be built on. Training is an essential part of the foundation of any successful security program, and even if it seems to derail the day-to-day job, incorporating it improves code quality and overall security. In the next blog post we’ll discuss some best practices on how to implement training in your security program. Stay tuned!

                  Related Articles

                  Getting started with Kotlin

                  Getting started with Kotlin

                  Reading Time: 10 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?

                  Life Before Docker and Beyond – A Brief History of Container Security

                  Life Before Docker and Beyond – A Brief History of Container Security

                  Reading Time: 11 minutes Containers have been around for over a decade. Yet before Docker’s explosive success beginning in 2013 they were not wide-spread or well-known. Long gone are the days of chroot, containers are all the rage, and with them, we have a whole new set of development and security challenges.