Shifting security left, one step at a time
I was recently asked about the status of Information Security as a salient feature of the product roadmap.
I paused.
The question by itself seemed to hold up a mirror. It showed how security is viewed in today’s digital-first, app-centric, customer-focussed world. It may seem innocuous but under it lies the silent struggle many corporations face today. It also carries an unarticulated question: how should one align security with business imperatives?
In the context of a SaaS company such as Freshworks, at which point in the product development roadmap does security come in? How does it compare with the other inflection points in the product curve? Should it enter the picture at the Build phase or even earlier at the Design phase? What are the trade-offs vis-à-vis product velocity?
Questions abound.
At Freshworks, these do not bounce off in echo chambers nor seem like conundrums; they are just accepted challenges for which the answer is: it’s a process and we’re making progress every day. We’ve decided that we are going to shift security left—closer to conceptualization so that it plays a much wider role in the process of building products; so much so that at one point our products are secure by design.
There you have it, our two security cornerstones: Shift Security Left, and Security by Design.
Here are two scenarios where security plays important roles:
- While adding feature functions to a product—say, you are adding Single Sign-on for access—there are a host of vulnerabilities inherent in the process. Prioritizing security at this point raises the robustness of the product. Of course, this is a juncture of trade-off between security and product velocity. No prizes for guessing which side to lean toward.
- During the Build Phase. This is the point where you might be hunting for reusable libraries for your coding requirements. The bad thing about them is that they come with vulnerabilities. Again, prioritizing security at this point—where we incorporate libraries to our codebase—will enable security primacy.
In product development, security is now being considered as a must-have weapon in the box at the feature and build phases. Ideally, it should have been the design phase itself.
The modern-day threat scenarios
In the post-pandemic world where digital transformation is seeing higher adoption, threat scenarios are getting multifarious. Consider for a moment the extent of data transfer between applications—or between one section of the app and another—in our mobile phones. We live in an era where multiple applications involving credit card pins reside on the same screen in a mobile phone, all of them kept apart by a membrane of password-based security. There are potential vulnerabilities of opening up sensitive data to bad actors.
Secondly, we live in a world where customer support is delivered on chat windows. Be it a package delivered from an e-commerce site or a cab winding its way through rush hour or a midnight hunger-quencher, there is now a window of customer support that’s exclusive, responsive and capable of quick resolution.
Such convenient scenarios come with their own chinks in the armor. Consider for a second if your benign chat window is repurposed to insert JavaScript for server-side manipulation. This type of cross-site scripting, SQL injections, and similar malevolent attacks rank among the common attempts to infiltrate a system (just take a look at OWASP’s top ten vulnerabilities and you’ll know more about what I’m talking about).
This is where security by design comes in. Even as the product managers are designing the product, they should think about the potential security risks.
Our approach to security evangelism
Understanding modern-day security concerns is just one part of the problem. The thought leadership resides in the execution of it. How do you enable an entire organization to take Security by Design to the very heart of what it is building? How do you make product managers, owners, and engineering leaders to have the same spirit of security?
At Freshworks we evangelize this through a two-pronged approach: top-down and bottom-up. This means the people at the top first believe in it, and then talk about it to their colleagues. Even as this sensitization goes on, we educate our colleagues working on products and features about security vulnerabilities and threat perceptions.
To truly adopt a security-first approach, we knock off the silo separating software development and security testing and bring in the actual work of securing our products in the Continuous Integration/ Continuous Delivery cycle.
Then come the important frontiers in making this real—People, Process, and Technology:
People: Get everybody involved in the shift-security-left transition to embrace the challenge. Get them invested in the spirit of it. It’s like traffic rules. You need to follow them.
Process: Integrating security all along the development cycle is like adding more bars to a sheet of music you’re playing on the piano. It’s going to take a little longer to get to the finishing note, but it’s worth it.
Technology: Challenges abound. This part involves dealing with many technological requirements while not losing sight of our target to infuse security into the development process. This requires:
- Repurposing security tools to work in modern, hybrid development environments;
- Adopting the right measuring tools to track bug-tracking and reporting performance;
- Choosing the right open source tools and building intelligence on top of them; and
- Prioritizing security decisions by basing them on data-driven information systems.
Our vulnerability dashboard
At Freshworks, we run a dashboard of vulnerabilities. It’s a live scorecard for our product leaders to understand the threats they are dealing with. In real time, we tell them, in a format that goes down to the highest levels of granularity: “Hey! Freshdesk, these are your gaps; Freshsales, you need to buck up on this front.”
This way, we show them exactly what we’re talking about, so that security is not an abstract concept flying somewhere in the cloud. It’s real and on the ground. This energizes our folks to fast-track corrective measures on security, and also makes efforts and results totally metric-friendly.
There are a range of threat modeling techniques out there, each with its own limitations when implemented in isolation. The trick then, as eloquently put down in this paper by my colleague Sriram Krishnan, Sr. Security Engineering Manager at Freshworks, is to go for a hybrid model.
Efficient feedback to field executives and constant evangelism at the leadership level is a holistic approach to security. Secondly, since most of our products involve information exchange and interactions, one product experience is at once an instance of learning for several others.
If there is a security misconfiguration in one of our products, it’s an instance of learning for our entire gamut of products. Efficient cascading of this information across the board enables learning beyond product borders.
The million dollar question every CISO faces
In today’s world of SaaS where feature releases happen ever so frequently, and calendars look choc-a-bloc every month, every Chief Information Security Officer needs to answer this question: Does Security by Design require altering the product roadmaps? If yes, by what degree is it a disruptor? Can feature functions be hammered out as easily as before in a Secure-by-Design environment?
The reality is that product efficiency is measured on benchmarks of product velocity and feature efficiency. Here is a confluence of three different stakeholders: product leadership—measured on the yardstick of meeting market demand; engineering—measured on feature velocity, and feature predictability; and Continuous Testing—picking the product fabric for vulnerabilities and inconsistencies all along the complete lifecycle.
Hence, it’s highly important that the three groups align on acceptable thresholds. Just because I love one feature, am I going to work on making it the best while ignoring others, or am I going to deliver on the other fronts too at an acceptable level? The same conversation should be held from a security perspective too, and the conclusions should be followed through diligently.
Apart from the obvious intent of being the umbrella panel for information security, the ISSC has, among others, the following responsibilities:
- Identify Information Security goals, chart and implement them
- Review effectiveness of implementation through omniguard controls (Control catalog developed by Information Security Team based on risk assessment and applicable standards)
- Provide clear and visible management support for security initiatives
- Kickstart plans and programs for driving InfoSec awareness
With a well-structured and well-evangelized security mandate in place, it is possible to put into action the top-down, bottom-up approach I’ve mentioned above.
Time for a Security Constitution
So, broadly, that is how we are putting security into action. It’s important that organizations lay down a Security Constitution, an all-encompassing document which would set in stone the responsibilities, tasks and targets, so that the journey is clear for a longer course of time. Going forward, SaaS organizations would gain more trust by demonstrating their robust security features, and talking a lot about their sensitization programs to evangelize these measures.
When I think about it, looking at it from a bird’s-eye view, I understand that security is about keeping the trust. Our customers trust us with their data, their privacy, their dignity.
So, do unto others as you would have others do unto you.
That’s what security means for me, and for Freshworks.
PS: Sriram is training his glass on some tricky threat scenarios facing the SaaS world. He is also contributing to a global attempt to take DevSecOps to the next dimension. Watch this space for Part II.
