SafetyDetectives had the opportunity to speak to Nir Valtman, Co-Founder and Chief Executive Officer Arnica.
Nir is an experienced information security leader with over 13 years of experience in the space. Nir is a frequent public speaker at leading conferences globally, including Black Hat, Defcon, BSides, and RSA. Previous to Arnica, Nir was on the advisory board of Salt Security, CISO at Parameds.com, and VP Head of Product & Data Security at Finastra.
We discussed the company’s early days, and analysed the different types of software supply chain attacks and how Arnica helps business owners prevent them (plus some tips to make your supply chain even more secure).
What’s The Story Behind Arnica: How Did It All Start, And How Has It Changed During The Years?
Back in 2020, when I worked at Finastra as the VP of Security, our CEO heard about the software supply chain attack against SolarWinds. He knew that our application security program was mature, and as expected, asked me what we were doing to avoid being in the same situation – especially given the sensitivity of Finastra’s FinTech software.
The concept of the software supply chain was emerging and so I did not have an immediate answer. I set out to find the solution, but I did not expect it to be so challenging.
My teams and I met with dozens of security companies and ran a handful of POCs. Most of the solutions were too narrow (e.g., signing components, checking misconfigurations) or ended up increasing our operational cost significantly (e.g., automating threat modeling after the code is implemented, instead of during design).
None of the vendors solved the root causes to software supply chain attacks holistically, so I approached a roadblock. And thus, the idea for Arnica was planted!
I joined forces with my co-founders, Moshe (Diko) Dahan, and Eran Medan. The three of us saw the same challenges from different angles – each with our different backgrounds in security, operations, and engineering, respectively. We had dozens of conversations with CISOs, DevOps, and engineering leaders to better understand their challenges and how to solve the software supply chain security problem.
We learned that providing visibility to risks is important, but that this is only a sliver of the challenge. More importantly, we realized how crucial it is to make it easy to actually fix the risks. And on top of that, the mitigation for each risk must be presented and executed in a way that doesn’t hinder development velocity – or better yet, accelerate it.
It was then that we decided to leave our comfortable jobs and pursue the vision of a world in which software development is unimpeded by risk.
What Kind Of Cybersecurity Services And Products Do You Offer, And What Makes Them Stand Out?
Software supply chain attacks surprise everyone. Based on our research, the root causes of all attacks since 2018 can be bucketed into two categories: (1) improper access management to the development ecosystem, or (2) an inability to identify anomalous identities (users and automation accounts) or risky code behavior. Arnica officially launched the general availability of the solution late October, and here is a synopsis of the features.
Self-service developer access management
Arnica takes a behavior-based approach to software supply chain security risk mitigation. Starting with the challenge of improper access management, Arnica identifies excessive permissions to your source code and mitigates them in a single click. We do this while providing self-service access capabilities to developers via Slack so that requesting or regaining permissions is easy. For example, a company can decide (based on policy) to automatically re-grant any permission that was revoked in the last 90 days; but, when a new developer requests permission to a sensitive code repository or branch, the request will route (based on policy) to a specific Slack channel for approval. Then permissions are provisioned automatically when the request is approved.
Here is an example of the developer’s experience using Arnica’s Slack bot.
One of the exciting things about Arnica’s patent-pending excessive permission mitigation approach is that it tells you which permissions will be effective after the change. For example, when Admin permission is reduced Arnica will grant the minimum permission needed by the user based on their specific historical behavior.
Risky code starts with hardcoded secrets
Code risk is one of the big domains we decided to tackle incrementally, and we started with mitigating secrets in code. Yes, you read it correctly – Arnica’s patent-pending solution doesn’t only identify hard coded secrets, but it also fixes them! Mitigating hardcoded secrets is hard. It requires the developers to rotate the secrets as they are always kept in the git history. The best solution I have seen to prevent developers from pushing secrets thus far is with GitHub Advanced Security, and I warmly recommend using it if it is an affordable option for your company and acceptable by the developers. However, not all secrets are equal and not all developers know how to rewrite the git history to remove the newly checked in secrets from their code. Therefore, we decided to let the developers choose the easiest way to mitigate secrets by them immediately after the code is pushed to the source code repository.
How would you know what the developers did and what is the status of every action? Here is an example:
Anomalous developer behavior
The developer is becoming an increasing target for attackers, as such account takeover can cause an injection of malicious code or source code exfiltration. Additionally, while we assume that most developers have good intentions, the concern around insider threats spiked, especially since the tension between Russia and Ukraine started. Arnica runs machine learning to profile each developer’s behavior and then inspects every new code push against more than 3000 characteristics. When abnormal behavior is detected, an automated workflow can be kicked off to immediately mitigate the risk. For example, Arnica can send a direct out-of-band message to the developer and ask if the code was pushed as expected and add a comment on the Pull Request to require another set of eyes on the anomalous code change before the code is merged into your production code.
Below is an example of a message that a developer gets on Slack:
In case you are curious about false positives, I can assure you that false positives do exist with every machine learning algorithm. Arnica enables you to set the custom threshold that fits best to your risk appetite.
What makes Arnica stand out?
- Arnica mitigates risks vs. only showing a ‘single pane of glass’
- Self-service product experience
- Enhances development velocity
- 1-click setup, no code or CI/CD pipeline changes required
- 100% coverage from day 1
- Low operational risk – revertible mitigations
What Are The Main Cybersecurity Risks In Software Supply Chain Nowadays?
With the increased trend of cloud-native technologies and supporting automation tools, code can be deployed to cloud environments in minutes from the moment a developer pushes the code to the source code management (SCM) system.
Excessive developer permissions to source code can lead to risky code changes in your production environment without being aware of it. Risky code changes can be pushed inadvertently by utilizing a known or unknown malicious 3rd party open source package or deliberately by injecting a backdoor. And because developers have increasingly become targets of security threats, a developer account takeover could lead to source code exfiltration. Typically, companies with sensitive IP (e.g. algorithm to calculate a credit score) or hardcoded secrets (e.g. credentials to your cloud environment) will care more about it.
What Other Tools And Practices Should Businesses Implement To Keep Their Software Supply Chain Secure?
- Start with having visibility into your development ecosystem. For example, identify which permissions are excessive, identify branch protection misconfigurations, check MFA enablement vs. enforcement, etc. While most of this data can be pulled via APIs from the SCM tools, Arnica provides this full visibility for free for unlimited users and code repositories, forever.
- Scan for hardcoded secrets in source code. There are many open source projects that provide such scanning, but this is also part of Arnica’s freemium.
- Scan for vulnerable or low reputation open source packages. Yeah… this is freemium too, but you can use great open source projects like Trivy.
- Develop techniques to identify anomalous behavior in the development ecosystem. You can start with streaming the audit logs to your preferred SIEM and building logic around it, such as identifying users who clone more than X repositories in Y time.
By taking these steps, you can understand better what is the attack surface of your software supply chain. This is important because it will help to strategize which risks should be mitigated and in which priority.
Is There Any Recent Cyber-Attack That Concerned You More Than Others?
As I stated above, software supply chain attacks surprise everyone. They can target the developers, the source code managers (SCMs), automation tools (e.g. CI/CD pipelines) and other 3rd party channels. As of now, it looks like the root causes are the consistent – improper access management or inability to detect anomalous behavior in the development ecosystem, which is what we are solving.
And What Cybersecurity Trends Do You Think Will Be Crucial In The Near Future?
This one is easy – software supply chain security. The main reason is that cloud adoption and maturity has been growing exponentially in the last few years, which made many IT assets and applications more secure by default. As a result of it, the new vectors to attack organizations are focused on account takeovers and open source software leveraged by the application developers. Additionally, since the development ecosystem is developer friendly, misconfigurations tend to occur, such as exposing private repositories publicly, and excessive user and personal access token permissions.