'Inside Security' with Ashwin Ramesh (Detection & Response Security Engineer, Plaid)

Our second edition of Inside Security features Ashwin Ramesh. He is currently a Detection & Response Security Engineer (E4) at Plaid, and prior to that he was a Detection Engineer at Expel.

Unlike Veer Singh from our previous interview, Ashwin's interest in security was sparked academically during a college semester. He took a course on cybersecurity that required a project submission, which focused on highlighting how poor implementations of the RSA algorithm made it susceptible to brute force attacks. The project received an award that semester, igniting a deeper passion for the field.

Around the same time, Ashwin was captivated by the series "Mr. Robot," which showcased real-world hacking, unlike the typical Hollywood portrayals we had seen before. Both the academic project and the series played pivotal roles in Ashwin's deep dive into the world of security.

Trade-off: Work or study?

After graduating from Vellore Institute of Technology, Ashwin weighed the options of gaining work experience versus continuing his education. Although he valued practical industry experience, he felt his single semester of security coursework was insufficient and wanted to deepen his understanding of various aspects of the security industry through further academic study.

“It was my understanding then that had I chosen to go into the workforce, I might have been pigeon-holed to do one thing, whereas, I wanted to get a broad sense of the security industry, and then double down on something that I knew I could be great at, and I think I did the right thing.”

This decision led him to pursue his Master's degree in Computing Security from the Rochester Institute of Technology (RIT).

This was a pivotal decision for Ashwin, as he began to find his footing in the industry. At RIT, he had the privilege of studying under Prof. Jonathan Weissman, a Principal Lecturer in the Department of Cybersecurity. Under Professor Weissman's guidance, Ashwin delved into malware reverse engineering and network security, writing numerous scripts and tools that deepened his understanding of the technologies used by security engineers.

Upon completing his degree, Ashwin faced a crossroad: he could either enter the industry as a penetration tester or become a part of the blue team, focusing on log analysis, filtering, and mitigating security threats. He chose the latter, embarking on a career dedicated to enhancing security through improved detection methodologies.

Culture meets Security: Expel and Plaid

Top talent looks for environments where they can thrive, be challenged, and make a significant impact. Companies with a compelling vision and a vibrant culture are more likely to draw in high-caliber professionals, as they offer not just a paycheck but a fulfilling and enriching career experience.

At Expel, Ashwin was drawn to the company's investigative mindset, which broke down security into five fundamental questions: what, when, where, why, and how. Simple yet effective.

However, the journey to Expel was not straightforward.

Expel operates like a startup but interviews like a much bigger company, being extremely stringent. The company interviews up to 400 candidates, sometimes even tracking them over a period of time, before narrowing it down to a final list of 10 to hire, ensuring only the most passionate and capable individuals join the team.

Speaking from first-hand experience, Ashwin recounts how he wasn’t the first-choice when it came to hiring but he showed enough promise to keep Expel interested in him.

“Initially, when Expel visited the campus six months prior to graduation, they decided I wasn't quite ready to make the leap. However, I was determined to prove them wrong. Over the next six months, I demonstrated significant progress through projects, academic work, and understanding the industry better. When he came back around for their second round of hiring, they could visibly see the difference. After a set of interviews, Expel decided to extend me an offer.”

On the other hand, Ashwin was drawn to Plaid’s forward-thinking outlook on security. Plaid’s approach to security is somewhat similar to Netflix's, emphasizing the importance of developing everything internally. This philosophy means that security is not solely the responsibility of the security team but is a shared duty among all members of the engineering and product teams.

“Within security engineering, your goal is to protect your customer. At Expel, being a vendor, I had multiple customers, but at Plaid the focus narrows to a single customer - Plaid itself.”

Having a single point of focus allows for a more concentrated and deep approach to security. The security team's efforts can be fully aligned with Plaid's specific needs, business goals, and risk profile. This singular focus can lead to more robust and cohesive security strategies, as the team can invest all their resources and attention into understanding and mitigating threats specific to Plaid, than multiple clients.

As he spoke to us, it was clear he had grown in experience and confidence from his past role, now ready to embrace more demanding positions with less structure.

Life as a Detection Engineer

The life of a detection engineer is marked by a constant balancing act between proactive measures and reactive responses. They are tasked with designing, implementing, and maintaining systems that detect and respond to security threats in real-time. Their role is dynamic and requires a blend of technical skills, constant learning, and strategic thinking. It’s best suited for those who thrive in fast-paced environments.

Some of the day-to-day responsibilities of a detection engineer involves:

• Writing detection logic, queries, and rules to identify specific malicious behaviors or techniques across log sources and data feeds.
• Continuously tuning and maintaining existing detection content to reduce false positives and ensure effectiveness against evolving threats.
• Collaborating with threat intelligence teams to stay informed on new adversary tactics and translate that knowledge into new detections.
• Engaging in threat hunting to proactively identify potential threats not covered by existing detections.
• Setting up log ingestion pipelines and normalizing data sources needed for detection.
• Documenting and transference of knowledge - it’s important that a team is able to function when you’re not the engineer on call

As a first-time detection engineer, Ashwin quickly understood the critical nature of discerning between benign and malicious computer behaviors. Although this task initially appeared straightforward, it was more complex in practice. He faced the challenge of managing a high volume of alerts, with 600 to 700 alerts per shift, which underscored the need for precise and effective detection tools and features.

This workload and the intricacies of detection further emphasized the necessity for detection engineers to continually develop their skills in creating sophisticated detection logic and rules. By analyzing log data thoroughly, they can craft effective strategies to identify and mitigate security threats, ensuring a robust defense for their organizations.

Logs without context

Lack of context in logs leads to challenges in troubleshooting and root cause analysis, as it becomes difficult to trace a specific log entry back to the original request or transaction that triggered it across different components of a distributed system. This results in a painful experience of sifting through isolated log entries without the ability to easily correlate and investigate related events and issues.

Ashwin highlights this issue cropping up regularly as a detection engineer:

‍"We often lacked enough context with our logs, which hindered my ability to fully resolve issues."

Logs generated across various layers like application, system, and network complicate correlation efforts, necessitating tools that enrich logs with additional context, such as request IDs or user information, to improve traceability and analysis in micro-services architectures.

To navigate through the noise, Ashwin suggests engineers develop simple tools internally, that would allow you to quickly connect to a security tool or case management software. As a detection engineer the most fundamental process is to gather data for investigations, metrics, or future feature development. A useful skill to have is the ability to script in Jupyter notebooks, this speeds up code development without having to worry about infrastructure management.   

"At Plaid, I developed a service that systematically analyzes all incoming alerts, incorporating extensive filtering and customizable configurations. This tool effectively reduces the volume of alerts by distinguishing between routine noise and genuinely suspicious activities that warrant further investigation. As a result, we can focus our efforts on addressing incidents that truly pose a potential threat.”

For a detection engineer context is king. Without the right framework, and tools one would have complete visibility into an organization, without knowing what they’re looking at or where these events originated from. Engineers are then forced to depend on documentation from the vendors to glean additional context, and considering how  good documentation is hard to come by, it’s becoming common practice that most security teams do not fully utilize the datasets that they have access to..

There are numerous vendors, and naturally, this leads to a variety of challenges in log management. Each vendor has its own unique definitions within their logs and different methodologies for logging data. For instance, some may prefer a process-based orientation for their datasets, while others opt for a workstation-based approach. Both methods are perfectly valid and offer useful perspectives on the data. However, this complicates the process of aggregating these logs into a unified format and can be quite challenging.

Lack of Alignment within Security

Security constantly evolves alongside prevailing technology trends. For instance, as cloud attacks became more frequent, we observed a surge in cloud security providers. Prior to that, the focus was largely on enterprise or on-premises solutions. Currently, the emergence of AI-driven security solutions is becoming increasingly prominent.

Although there’s a need to experiment and ‘get with the times’, Ashwin emphasizes there needs to be a more robust framework around decision-making and building a company’s tech stack.

“One of the recurring issues in the industry is the tendency of security professionals to invest in flashy new tools that largely replicate the functions of existing ones. This often results in redundant technology stacks within organizations. For example, some customers may employ multiple products that serve similar purposes but differ slightly, such as in the quality of the logs they generate.”

However, Ashwin suggests that it's crucial for teams to regularly reassess their tool stacks—ideally every three to six months—to determine whether to continue with current solutions or integrate new ones to address new security control / visibility gaps. This practice helps streamline operations and ensures that investments are made in tools that genuinely enhance security measures rather than merely adding to the clutter.

At Leen, we have a thesis around this: Security is a data problem, and security has a data problem. For instance, throwing more tools at a problem won’t always solve the problem. This could result in too many tools with different levels of API maturity, formats and perspectives on the same finite set of assets within an environment. This is what Leen is helping security engineering teams tackle.

Future of Security is Engineering

Ashwin is confident that the future of security will be driven by engineers. He firmly believes that engineering expertise will be at the forefront of advancing security practices.

“We're now seeing a significant increase in undergraduates and graduate students entering the workforce with a robust understanding of security protocols and practices. This marks a shift from the past when many in the security field had originally started in IT and gradually moved into security roles. This narrative was common around 2010-15, but it's less frequent today. Currently, more individuals are intentionally studying computing security or have pursued it passionately, perhaps even through projects that led them into the industry after dropping out of college. This new trend underscores a growing specialization and early interest in the field among emerging professionals.”

Security is all about storytelling

This is something we believe in as well. Security isn't just about technical measures and defenses; it's also about conveying the risks, threats, and the steps needed to mitigate them in a way that is understandable and actionable by all stakeholders involved.

“Everything within security can be daunting if you let it be."

Take, for instance, the task of reviewing logs during an investigation. When faced with a 1,000-line spreadsheet, it’s easy to feel overwhelmed. This feeling persists only if you approach it linearly. Instead, try gradually filtering the dataset to reduce it to a more manageable size. By viewing log analysis as piecing together a story rather than just sifting through data, the process can become not only manageable but even intriguing.

Ashwin's journey from academia to industry showcases the importance of determination, continuous learning, and the value of a supportive team in the field of security engineering.

To connect with Ashwin, you can reach out to him via his LinkedIn profile.