The experience I accumulated leading the cybersecurity function in higher education, U.S. government, and U.S. military was insufficient to prepare me to lead the security function in engineering-centric organizations. After moving to Silicon Valley in 2014, I had to learn additional skills and change my approach to cybersecurity to become effective in an engineering-centric agile organization. That being said, there are three practices security executives should consider when leading cybersecurity in an engineering-centric organization:
1. Know the Business
It is essential for security professionals to understand the business of engineering-centric organizations. Knowing the business is always important regardless of industry, but it is even more crucial in engineering-centric organizations. The security function should be well-versed in the following:
• How the organization makes money.
• All products and services offered.
• The road map, including strategic organization goals in the next six months.
This knowledge will allow the security team the opportunity to do their jobs successfully. Truthfully, security cannot be accomplished in isolation of business functions — it’s not an island. It should never impede the success of a business. Additionally, security should not be the department of “no.” Time and time again, I’ve seen security teams shutting down practical ideas businesses have. Instead of saying no, security teams should always be looking for ways to uncover additional practices, allowing business to happen safely and securely. In other words, security needs to facilitate the accomplishment of the organization’s business objectives. Security should:
• Enable sales.
• Shorten the sales cycle by removing any friction to closing deals.
• Be a partner to engineering, marketing, and sales.
• Be customized to the organization’s culture.
• Be aligned to the risk appetite of senior management and the board of directors.
And this is just the beginning. All in all, security executives would do well to consider business training, even earning a Masters of Business Administration.
2. Develop Soft Skills
To successfully lead cybersecurity programs in engineering-centric organizations, information security executives need more than just technology skills. In addition to business skills, developing soft skills is crucial. The security function needs to understand and get along with all the other business functions of the enterprise. As an Information Warfare Commander in the U.S. Navy Reserve, the number one rule of military leadership is to “take care of people, and people will take care of the mission.” The focus needs to be on people.
In some of my past workplaces, the security team sometimes joked about engineers being delicate geniuses, snowflakes, or prima donnas. All jokes aside, the security executives need to spend time getting to know their engineering team members on a deeper level — outside of stereotypes. When engineering and other teams see security as a business partner and enabler, there will be more synergy among your workers.
In contrast, when workers see the security team as an abstract group of individuals on high horses — shouting orders at everyone, not listening to anyone, and being an obstacle to business requirements — the security function has failed the business. Security executives need to lead, even during uncertain times. Leadership is based on trust and dependent on relationships to succeed. Security executives would do well to improve their softs skills, increase their emotional intelligence, and deepen their relationships with other key business executives.
MORE FOR YOU
3. Mitigate Vulnerabilities in Production
Unlike higher education or government organizations, engineering-centric companies in Silicon Valley develop code at the speed of thought. After moving there, I was initially shocked to find out that my organization developed code in two-week sprints. Before this experience, I was accustomed to the government and higher education model, taking as long as six months to a year to develop new code. Using agile methodology, most tech organizations develop code in fast increments and iterate.
To secure the Software Development Life Cycle (SDLC), I recommend that security executives initially focus on areas of most risk: mitigating significant vulnerabilities in production as quickly as possible. Start leading a data-driven security program, informed by the most recent risk assessment to prioritize and focus limited resources where it counts the most. The idea is to find and mitigate known vulnerabilities in production before hackers find and exploit them.
To this aim, I am a big fan of red team exercises, such as where one team attacks the code, while another tries to defend it. Penetration tests come to the top of the list. Most security frameworks require at least one third-party-led penetration test every year or whenever there are material changes to the code. I have worked for organizations that barely performed penetration tests annually and others that performed semi-annually, quarterly, and even monthly penetration tests. The more an organization performs penetration tests, the more opportunities to detect and mitigate exploitable vulnerabilities in the codebase.
However, penetration tests can be costly. The best cost-effective strategy I have found working in fast velocity engineering-centric organizations has been to couple a third-party annual penetration test with an automated web application penetration test, aligned with the organization’s sprint cycle. The automated web application penetration test costs a slim fraction of a third-party penetration test and provides continuous visibility into potential vulnerabilities in the code.
Another essential tool is the use of bug bounty programs. Using bug bounty programs, security executives invite world-class security researchers to find and attempt to exploit vulnerabilities in a sandbox environment that runs the same code as the production environment. This way, security researchers will find vulnerabilities and be rewarded based on the severity and exploitability of vulnerabilities found, giving the security team a chance to mitigate them before hackers exploit them.
As the security program matures, it would be ideal to shift security left of the SDLC, all the way to the development environment as close to each developer as possible. The idea is to have each developer test his or her code for known vulnerabilities before merging into the main code repository. This is also a learning opportunity for developers as humans are creatures of habits. How someone does something is usually how someone does everything. By detecting security flaws or vulnerabilities as early as possible in the SDLC, developers get a chance to learn how to develop code more securely and avoid repeating the same mistakes over and over again. Also, it costs much less to fix security bugs at this stage than it does after the code has already been deployed to production.
Relearning Security Practices in an Engineering-Centric Organization
Leading the security function in an engineering-centric organization is very different from doing so in higher education or government organizations. In addition to superb technical skills, security executives in engineering-centric organizations also need to focus on the business, develop soft skills, and strategize on mitigating significant risks in production as quickly as possible while aiming to eventually shift security left of the SDLC.
