Security Compass’s CEO, Rohit Sethi, spoke with Laksh Raghavan as part of the Security Leaders series in our The Balancing Act podcast. The Balancing Act is a regular series of interviews with security practitioners on the challenges they face and their personal journeys.
Laksh has been Director of Information Security at LinkedIn since 2020 with responsibility for product, platform, and enterprise security. Prior to LinkedIn he spent 11 years at PayPal, rising from a Staff Information Security Engineer to become Director of Security Products Development. In this role he led product development in the areas of Application Security, Data Security, Crypto, Identity & Access Management, and Cybersecurity Operations.
You will find the entire podcast educational. Below are some of the highlights.
He is a strong proponent of understanding behavioral science
Laksh does not believe we as an industry have enough evidence about what works well and what doesn’t to call security a “science”. In the meantime, “We have to embrace what works and discard what doesn’t.”
He draws heavily on behavioral science, spurred by an incident early in his career when rolling out a static analysis solution. His team produced a training video for the development teams and found the clickthrough rate was “abysmal”. They resent the email with a small edit, adding “three minutes, 22 seconds” to indicate it was a short video.
“The click-through rate was through the roof, and it was really eye-opening for me. And it felt like a superpower. And ever since that, I just poured myself into behavioral science and embraced the spirit of experimentation.”
Laksh believes the human element drives change, as does “the power of peer pressure”. Making dashboards open to all allows peers and managers to see how each team is performing against goals.
“You have to go where the developers are”
Laksh believes a “security teams’ success lies in influencing the actions, roadmaps goals of product development teams.” In most cases, it must do so without any operational control over what development teams do. This applies to security requirements as well. The old way of meetings between product and security teams then tracking requirements by spreadsheet simply is not effective when development is under pressure to deliver functionality.
This means security needs to “make sure that the requirements actually go to the place where developers are going day in and day out” like Jira and other tools. He believes this can produce a wave effect as well, where teams such as privacy, legal, and compliance observe the effectiveness of the approach and adopt similar strategies.
“Systems thinking” produces better results
“Systems thinking” looks at solving environmental problems as a way of addressing point issues. He uses the example of the decline of the ecosystem in Yellowstone National Park years ago when large game was defoliating large sections. A point solution would be to address the symptoms such as water flow. Instead, they looked at the big picture and decided to reintroduce wolves to the park. This effort resulted in eld migrating to other areas and a growth in the population of other species such as beavers and mice. “Plant life started to thrive again on riverbanks and erosion decreased significantly.”
The same system thinking rules apply in security. In Laksh’s words, “Don’t try to improve part of a system in isolation. 
In most cases, it’ll actually deteriorate the whole.” He uses the example of the security concerns around open source components. On the surface, this appears to be a vulnerability management issue. Laksh argues well that it is really an asset management problem. You need to know what is running in your environment and manage that closely. “If you don’t have a configuration management database (CMDB), then put that in place… and collaborate with all [reliability engineers], developer experience teams…all your partners. When asset management is significantly improved, that’s laying a strong foundation.”
How to start a security program
Laksh believes “the typical journey is from reactive to proactive.” Organizations focus on pen testing and vulnerability management then focus on remediating those specific issues. He encourages teams to also focus on preventing those issues from entering the code base or infrastructure. “Let’s shift left, let’s start providing [developers] with security requirements up front. Let’s do threat modeling. Let’s start investing in secure frameworks and investing in security tools. And so even there’s a maturity journey for each of those capabilities, starting from being manual and paper based, and then going into full blown automation.”
On management by outcome v. management by means
A manager’s language matters to the team. Laksh believes that asking about raw outcomes at each meeting results in fear of failure. While he strongly advocates for clear goals, he argues that a better question is “what are the improvement opportunities available and what is their expected level of performance improvement that they can deliver?” This leads to a mindset of continuous improvement. He uses the example of improving SLAs. By asking each week if a team is closer to the annual improvement goal, it focuses on the shortfall. Instead, he asks teams to discuss their strategies for improvement and what they need to implement those strategies. “If you focus on the means [for improvements] and what they’re going to do, you will start seeing magic.”
Solutions and “dissolutions”
Laksh’s focus on systems thinking extends through security. He believes as an industry, we often focus on solving a specific problem instead of “dissolving” the problem to make a solution unnecessary. He uses credential theft as an example. Solving this through education about phishing attacks, reusing passwords, and clicking on malicious links has not worked.
The systems thinking solution is to eliminate the need for passwords. With the work of the FIDO Alliance and adoption of WebAuthn, we are well on our way to a passwordless world.
Listen to the podcast here.