You may remember Andreas from his time at Synopsys, where he led the new Software Integrity Business Unit. He joined Tortuga Logic a couple of months ago to lead the company. Given his background in software security, I was eager to get a CEO interview. Andreas is a EE with background at IBM in the PowerPC and EDA. He directed Cadence Research Labs in the 2000’s, ran R&D at Coverity (static verification for software) and taught at UC Berkeley. Synopsys acquired Coverity in 2014, renaming it as the Software Integrity Group. Andreas, as GM of that group, grew it to a $350M/year revenue business. A big focus for that organization, driven also by multiple acquisitions, is application security. Andreas knows his way around the software security world, making him a promising catch for Tortuga Logic.
What’s your view on hardware security from the software world?
We’ve worried about security in software for a long time and a lot of work has been done to address problems. I’ve seen sophistication in attacks growing over that period, and defenses against those attacks continue to evolve. Hardware security had a flavor for a long time as fairly academic, but when Spectre and Meltdown hit, everyone woke up. Now we’re seeing an exponential growth in new vulnerabilities. Fixing software alone doesn’t help if the hardware can be hacked. I joined Tortuga Logic as CEO for this reason. I see a journey from security problems in hardware to scalable solutions which looks very similar to the journey we travelled in software. These lessons will help us address the challenges surrounding hardware security faster.
Tell me about the software security journey
Cyber security is a very broad, fractured field: endpoint security, network security, container security, firewalls, incidence response – you name it. Application security started moving to the forefront about 10-15 years ago when the traditional firewall started losing its central role in security. As apps moved to the cloud and to your mobile device, the attack surface became the application, itself. We saw application vulnerabilities and attacks, like SQL injection attacks, on an almost daily basis. Some attacks were so simple, high-school kids were doing them.
The financial services industry was among the first to recognize the threat. Responding though turned into a journey. First was to assess the business exposure – potential financial repercussions, brand damage, regulatory compliance – always balancing risk and investment. Early solutions mostly focused on a manual approach. Security experts applied threat modeling, penetration testing and code reviews to identify and remediate vulnerabilities. Later, part of the know-how was automated and embodied in various tools such as static and dynamic application security testing.
When applied as an afterthought, at a time development was almost finished, they would turn up hundreds or thousands of problems for which there was no time to fix. Security had to be pushed left into development. As security testing was adopted in the software coding phase, the security team could increasingly focus on governance, establishing the business requirements and overseeing implementation. This includes defining and enforcing policies that drive every phase of product planning, development and delivery – ensuring security priority was co-equal with other objectives. This is a continuation of the journey at a higher level of maturity.
Where is hardware security?
For many years, hardware security was a fringe activity; hacks generally required physical access to the device and had limited incentives for the perpetrator. Spectre/Meltdown changed the rules. For a number of hardware vulnerabilities, a hacker could now attack a device remotely. Just running software on a server that exploits such a vulnerability could get access to the foundation of the compute platform bypassing all security protections on higher levels. And the problem wasn’t a one-off. As researchers look closer, they are finding more and more vulnerabilities.
Where are we on the learning path for hardware security?
The fundamental process is the same. One needs to approach hardware security from a business point of view: what is the risk for the company and customers, what is the potential financial exposure, what about regulatory compliance, etc. You then compile business requirements into security policies, which you then then integrate into the product planning, development, testing and delivery process.
Following this approach, one should treat security as another form of signoff, like timing or power. I see hardware companies already working on putting such processes in place. For example, hardware roots of trust offer clear advantages. Reduce the attack surface by localizing the processing of security assets as much as possible. You still must ensure the root of trust is integrated properly and configured correctly, realizing that many of them are configured in software, often during the boot phase. Similar to software, security is a verification problem as much as an architecture problem.
In signoff, it’s important to accept that security is not a clean go/no go like timing. Security signoff is a risk signoff – what risk is a business willing to live with. In other words, how much effort do you invest in prevention versus managing a potential incident? This is why up-front business analysis is so important. There is no 100% secure design – therefore it is equally important to define an incidence response process to address a vulnerability. In software you can release a patch. In hardware – sometimes you may be able to release a firmware or OS update. However, provisioning such patches may be much harder than for application software. The maturity of this process is in a very early state, I think.
It is good to see that many hardware companies are already working on hardware security. I want to encourage them to approach security holistically. Start from a business perspective, then drive requirements on architecture, design, verification and security signoff. There are a number of emerging solutions to help build a comprehensive approach to hardware security,. These range from security IP components, verification products to security services and more. For example, we at Tortuga Logic offer security testing products that interleave in the design verification process and support a rigorous methodology for “building security into” semiconductor designs. Check us out.