Speaker

Niels Tanis

Niels Tanis

Sr. Principal Security Researcher at Veracode

Amersfoort, Netherlands

Niels Tanis has got a background in .NET development, pentesting and security consultancy. He also holds the CSSLP certification and has been involved in breaking, defending and building secure applications. He joined Veracode in 2015 and right now he works as a security researcher on a variant of languages and technologies related to Veracode’s Binary Static Analysis service. He is married, father of two and lives in a small village just outside Amersfoort, The Netherlands.

Area of Expertise

  • Information & Communications Technology

Topics

  • .NET
  • ASP.NET
  • ASP.NET Core
  • Security
  • Application Security
  • DevSecOps
  • .net core
  • C#

Using WebAssembly to run, extend, and secure your .NET application

WebAssembly (WASM) has come a long way since its first release in 2017. As a technology stack running inside the web browser, it even allows products like Adobe Photoshop to run in that context, and with Blazor WebAssembly .NET runs inside of the browser as well. Now, WASM is expanding beyond the browser to run in a server-based context. With the introduction of WebAssembly System Interface (WASI), the technology leverages a standardised API that allows it to run on any system that supports it, for example to support cloud-based workloads.
Had WASM and WASI been around in 2009, Docker would not have existed according to one of its founders, Solomon Hykes. WASM has a strong security posture given how it works with linear memory space and how it supports a sandboxed-based environment called “nano-process”, which uses a capabilities-based security model. Users can even take .NET and, with the help of WASI, run it on a Trusted Execution Environment (TEE) to add an additional layer of security.
In this session we'll start out with going through some of the basic security features of WASM and then move to running and extending an .NET application it with WASM. After that we'll focus on the security features and run .NET on a TEE and use the sandbox and the capabilities based security model to limit what it's allowed to do.

Securing your .NET application software supply-chain

With our complete software development process becoming more complex we also got a lot more security problems to deal with. What starts with code and ends with releasing/deploying software is also being referred at as the software-supply chain. The software supply-chain consists of a lot of moving parts. Each of them facing their own security risks starting from access to source code, compromised third-party libraries and tools, or even hacked build servers. For example with SolarWinds the compromised build server added malicious functionality to the end product used by their customers. And a tool called CodeCov had their upload script compromised which resulted in it stealing all used access-keys.
In this session we'll get hands-on with securing a .NET application it's supply chain and look how we can limit the security risks in all the different area's. We're going to use the guidance of Google's SLSA and using concepts like Software Bill Of Materials (SBOM).

Sandboxing .NET assemblies for fun, profit and of course security!

In our current way of developing .NET applications we rely a lot on third-party libraries developed by others. This of course has a lot of benefits from productivity perspective because there is no need to write needed functionality from scratch.
But by using in a third-party library you also pull in it's issues and possibly security problems that are found over time. What does the library do? And what type of other libraries and/or functionality does it rely on? What do the projects/people behind it do for security?
If we develop a .NET application using external libraries can we improve our security posture? Other new technologies like WebAssembly introduced a concept of nano-process, which allows the developer to limit the capabilities available for an external module by creating a restricted sandbox for it. Could we maybe do the same in .NET? In the old days we could use AppDomains and Code-Access Security (CAS) to achieve that, but with the introduction .NET Core there only is a single AppDomain and CAS has been deprecated.
Luckily with .NET Core we did get more internals exposed on AssemblyLoadContext and in this session we're going to create a sandbox using that. A restricted sandbox that limits the functionality available that will improve the security posture of our application!

Niels Tanis

Sr. Principal Security Researcher at Veracode

Amersfoort, Netherlands