Building an Application Security Program at VTS

At VTS, security is of utmost importance. Our products are the commercial real estate industry’s cutting-edge technology providing functionalities such as access, visitor and operations management, which require tight security controls and monitoring. And to do that effectively, we needed robust security practices that could be used across all of our products and services. That’s why the Security Engineering and Information Security teams at VTS have been working hard to establish a solid Application Security program that will help us protect our products, our codebase, and our client’s data. Programs like these are simply not established overnight. It will be a journey. Certainly an exciting one!

In this article, we will walk you through what is an Application Security program in the first place, the practices we’ve established and are currently building at VTS, as well as what the future looks like for our program and areas we’re planning on exploring in the coming years.

First of all… What is an Application Security Program?

To make it clear, the word “program” does not refer to the execution of computer instructions. In this context, a program is simply a set of application security-related activities established and implemented by our Security Engineering and Information Security teams.

We’ll go through these activities shortly, but think about how you can secure an application. And most importantly, when should you secure it — before, during, or after development?

Let’s take a look at some of the components of our Application Security Program and how we’re establishing them at VTS.

Components of our Application Security Program

Threat Modeling

Threat Modeling is an approach to identifying threats to a system and is an important first step to securing applications. Many people might think that applications should be analyzed and monitored for threats only once it’s running in production. They don’t realize that it can be an expensive choice for the business if threat mitigations/resolutions require an enormous refactor and developer hours. Engineering teams really need to think of threats as early as during the design phase of the software.

There is a misconception that only security experts are qualified enough to perform threat modeling. However, there are many well-established techniques that software developers and system engineers can use to threat model, some of which we use here at VTS.

Before core services go live, our Security teams collaborate with developers and go through a threat modeling exercise. We’ve used different methodologies and techniques to threat model, such as STRIDE and Attack Trees. However, given the size of our Security teams, it’s challenging to threat model every single service being launched. We’re constantly thinking of ways to scale our threat modeling practices and we’ll talk about some of our ideas towards the end of this article.

Application Security Training and Awareness

Let’s be real: we can’t expect every single Software developer to be a security expert. As much of an ideal world that would be, that’s just not possible. However, Software developers should see application security as their responsibility as well, and not just a responsibility of the Security Engineering team.

To make a parallel with the DevOps world, I am sure you’ve heard countless times the phrase:

It works on my machine, now it’s Ops’ problem!

By now, I hope you understand how problematic this mindset is when trying to establish a DevOps culture.

To succeed in establishing an Application Security Program, developers don’t need to be ethical hackers, but they should be aware of security fundamentals like the CIA Triad, Multi-factor Authentication and the different types of common vulnerabilities, such as SQL injection, Cross-Site Scripting or Cross-Site Request Forgery.

At VTS, we’ve partnered with Secure Code Warrior to provide Application Security training to our developers. The training aims to educate developers on known vulnerabilities, such as the ones aforementioned, plus many others like Broken Cryptography, Code Tampering and Client Side Injection.

Application Inventory

Imagine an organization with ten different products, and each product is composed of tens or hundreds of services. Then, a new critical vulnerability is disclosed and it’s known to affect an enormous amount of applications worldwide. Now, how can this organization be confident that this vulnerability does not affect any of their 10 products?

Enter the application inventory.

By definition, an inventory is a list of goods and materials held available in stock by a business. When it comes to applications, there are no physical materials, but there is code — your own and others’ (third-party libraries). So that means an application inventory is simply a list of applications owned by a company and these applications’ software dependencies. With an inventory, you know exactly which libraries your services are using, what version is running in production and whether or not a newly disclosed vulnerability affects your business or not.

We use an application risk management vendor (more on that on another blog post) to help us create Software Bill of Materials (SBOMs) and give us supply chain visibility across all of our products.

Application Security Testing (Automated)

When you think about running tests in a CI/CD pipeline as part of the Software Development Lifecycle (SDLC), developers immediately think about unit, integration, and end-to-end testing. These types of testing help deliver high-quality software, but not necessarily a secure one.

Earlier in the article, we talked about threat modeling. Threat modeling directs you on how your software can be resilient to common threats. However, as you develop code, vulnerabilities will naturally be introduced, and neither threat modeling nor unit testing will help you catch them. What will? Security testing.

There are many types of application security testing: Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Software Composition Analysis (SCA), Interactive Application Security Testing (IAST), to name a few. At VTS, one of the main goals of the Security Engineering team has been shifting security left and introducing some of these types of testing into our SDLC — meaning running these tests in our CI/CD pipelines alongside other types of tests and catching vulnerabilities as early as possible before they reach production.

Since last year, we have been leveraging GitHub’s CodeQL and Dependabot to find vulnerabilities in our code and its dependencies. And we’re looking to introduce other types of security testing into our SDLC in the near future.

Penetration Testing

Automation can only take you so far, and as much as we wish that automated security testing would catch most, if not all, of the vulnerabilities, that’s just not possible (at least at the time of this writing, you never know where AI and Machine Learning will take us). Automated tests only scratch the surface of the potential vulnerabilities that can be found in our code because they rely on what’s known. If you want to find the unknown, you need manual security testing and a talented team of Penetration Testers.

Penetration Testing is a simulated attack on an application, performed by professionals that use the same tools and techniques as real attackers, with the goal of surfacing weaknesses in the application and demonstrating the business impact that attacks can have. Needless to say, penetration testing is a crucial component of a successful Application Security Program, and its importance cannot be taken lightly.

We’ve partnered with an external vendor to perform annual penetration testing in all of our products and Cloud infrastructure. After we get reports with the vulnerabilities found, our Engineering teams work to resolve the most critical vulnerabilities and a few months after, we bring our vendor again for another round of test to make sure the vulnerabilities have been resolved.

Vulnerability Management

One of the goals of an application security program is to not only discover as many vulnerabilities as possible but also to resolve them. Having security tests and performing penetration tests is a great first step. Once you know where your application is vulnerable, many questions need to be answered:

• What are the criteria for defining a critical vulnerability vs a high or medium-severity one?
• How to properly prioritize all these findings?
• How long do we give developers to resolve vulnerabilities? 7, 14, 30 days?
• How to track progress as developers work on the resolution?
• How to give a risk score to a product knowing all of its vulnerabilities and their respective severities?
• What metrics will tell you that vulnerabilities are being resolved in a timely manner? And how to properly gather these metrics?

As you can imagine, there needs to be a well-defined process in order to answer all these questions, and that’s exactly what a vulnerability management program does.

Back in 2022, the Security Engineering and Information Security teams started working closely to define processes and policies which would be part of VTS’ Vulnerability Management program. Fast forwarding a year or so later, we are in a much better position to be able to visualize the health of our products and efficiently resolve critical vulnerabilities that are reported by our security tests tools and penetration tests results.

What’s Next for VTS’ Application Security Program

As the Security Engineering team grows, we envision many other components that can be introduced into our program to take it to the next level; let’s look at some of them — the first being the Security Champions program.

Security Champions Program

Security Champions are members of different teams within an organization that help with the organization’s security posture. These members do not need to be (but usually are) part of an engineering team and do not need to be security experts either. Remember when we talked about Threat Modeling and the fact that the Security team is too small to perform threat modeling in all new services? That’s one example of how Security Champions could help an organization scale.

A study conducted by Sonatype back in 2018 revealed that the ratio of developers to security professionals was 100:1. So, in an organization with 1,000 engineers and 10 security professionals, how can the Security team possibly keep up with everything going on? “Hire more security professionals,” you might say. Well, that could certainly be very expensive. A smarter and much less expensive approach would be to train developers interested in application security across the organization and pass on the knowledge so they act as an extension of the Security team. And did I say “developers”? Honestly, even Payroll or Finance team members can be Security Champions! In a future article, we’ll tell you about our journey with our Security Champions program!

Bug Bounty program

Have you heard that OpenAI, the company behind ChatGPT, is offering up to $20,000 for independent researchers that report vulnerabilities found in their product? That is thanks to their Bug Bounty program.

Bug Bounty programs offer monetary rewards to those who find critical vulnerabilities in an organization’s product and responsibly report these vulnerabilities. It’s not uncommon to hear organizations paying out millions of dollars to researchers and ethical hackers. And that is because depending on the vulnerability if successfully exploited by attackers, it could cause immeasurable damage to the business.

We currently don’t have a Bug Bounty program in place, but it is certainly an avenue we’re also considering exploring.

Red and Blue Teaming

In Cybersecurity, two main types of teams are used to test the effectiveness of an organization’s Security program: Red and Blue.

Red teams essentially use tactics, techniques, and procedures (TTPs) to emulate real attacks, often without warning. Some of the attacks might include social engineering, phishing, penetration testing, or even physical security attacks.
On the other hand, Blue teams defend the organization from all types of cyberattacks. Some of the activities performed by a Blue team might include monitoring systems for suspicious activities, investigating alerts and responding to incidents.

We’re currently focused on building the foundation needed by a Blue team to operate effectively, and we’d be looking at expanding and potentially building a Red team in the near future.

Conclusion

We are incredibly excited to build this program from the ground up and evolve our processes over time as we grow as an organization. As the famous saying goes: “Security is a journey, not a destination”, I’m sure we’ll always feel like we’re just getting started.

If you want to be part of this exciting journey and work with a small team of amazingly talented engineers, keep an eye on our careers page and look for open roles in the Security Engineering team.

We appreciate you taking the time to read this article, and we’ll see you in the next Security Engineering blog post!