At VTS we sell enterprise Commercial Real Estate SaaS products. Some of our customers include large companies with strict security requirements, and nearly every customer considers the information in VTS highly confidential. VTS realized early on that security would be critical to having a successful business. It can be difficult to meet these needs without having a full time security staff.

When I joined VTS I was pleasantly surprised with what I found. There was a small Security Committee and the basics of a compliance program. Information Security was in an excellent place considering there were only a few people thinking about security as only a small part of their job.

When I think about security at a SaaS environment like VTS, it can be divided into two very different major objectives: improve Product/Application Security and improve Organizational Security.

I’ve been at VTS for just over a year now, hired as the Director of Information Security. To borrow a term from Scrum, consider this, in part, my 1 year retrospective. This essay is how I think about security and the steps I took (or recommend others to take) to bring it to the next level.

A Plan, and a Framework

Regardless to who you officially report to as the first security hire, you are the subject matter expert and likely to be choosing what you work on yourself. You may essentially be your own boss. Nobody else understands this subject the way you do, which is why you were hired.

Speak to every department lead to understand each department’s needs, tools they use, and way they do business. Understanding your organization will help you secure it. This will also give you an idea of what you’re trying to protect and where the information lives.

To figure out where the risks may be, and how to prioritize what to work on, you can use a security framework and measure how your organization is doing. I used CSA Star. The act of fully completing the questionnaire will be a great learning experience.

After completing the CSA Star, I grouped items together into buckets based on types of issues. This helped me understand overall themes, and areas to focus on. It also helped me find and prioritize quick wins.

Prod Sec/ App Sec

As tempting as it may be to start tackling allthethings, trying to do everything all at once will lead to severe thrashing and have a lot of context switching costs. With that in mind, I think prudent that Product Security/ Application Security be prioritized over Organizational Security. Outsider threats are likely a higher risk than organizational or internal threats.

What I recommend to do:

Get very familiar with the product. Understand how the product works.

Understand all technologies and services that are being used to for the application stack.

Understand what the customer considers the most critical data, and how it’s being entered into the system, stored and protected.

Understand how permissions work.

Understand what logging and monitoring is already happening.

See if any existing technologies or services can also be leveraged or tweaked for security purposes.

How I did it:

VTS follows the scrum methodology with two week sprints and daily standups. One of the teams, at the time called the DASI (Data, ?, Security, Integrations) team, had the most responsibility for infrastructure and platform security. I essentially joined this team. This included attending the sprint planning sessions, sprint retro meetings, and the daily standups.

I worked very closely with the CTO and VP of Engineering to understand how they thought about Security, what they built, and what they already had in place. We still work very closely together today.

I started attending customer Due Diligence calls on my very first day to get familiar with the specific security needs of customers in the CRE industry, and to validate which data they considered most confidential.

VTS was already running static code scans, dynamic web crawling scans for security issues, and had a third party penetration test at the request of a client. I reviewed these reports thoroughly to look for common issues to address and any red flags or low hanging fruits. Logging and alerting was already configured for Engineering purposes; I was able to leverage this technology to add in some basic application security alerting.

The key takeaway is to really understand how the application works, and how the data flows through it.

Organizational Security

Next up was Organizational Security, or Org Sec. I think of Org Sec, as the security of the internal organization- of your employees.

Thought process and what to do:

There are some steps an organization should take to improve the Org Sec posture. This should in turn lower the security risk of the internal employees themselves. The very basic idea is to attempt to limit the damage that can happen from an employee’s mistake, misconfiguration, loss, or theft.

Some projects have probably been partially implemented toward improving Org Sec, but the key is to make sure what is in place is fully operational at scale. It is also important that Org Sec is easily reportable and consumable without a lot of manual work to expose gaps or non-compliance.

For example, on their first day, all employees were told to encrypt their laptops and given detailed instructions on how to do so. There were even efforts by the Security Committee to do spot checks and verifications. This is a really good effort but requires too much manual work and is not scalable. Improve on this by implementing an endpoint/laptop management solution to enforce and report on laptop encryption for all employees.

A few high level categories that I thought important to nail down right away were: email security, identity management for third party services (Okta/Ping/OneLogin/Etc.), Two Factor Authentication on any and all accounts that support it, and endpoint security for laptops/desktops. Entire articles, blog posts, and strategies have been written on each of these topics complete with ideas on implementation and product solutions; I will not attempt to solve or reproduce that here.

It is pertinent to understand where confidential or customer data is or will be stored, for example “shared drives” or subservice providers.

Identify these locations or key vendors and lock them down to the best extent possible. Look for any “features” or default settings that may expose or share data and review user access and permissions to these applications. For key vendors, it may make sense to form relationships with them with the goal of understanding their security practices, features, and roadmap.

In conclusion, I acknowledge there are many ways to skin the cat called Information Security. As the first security hire, it can be a difficult task to decide what to focus on. This essay represents some insight into how I think about security and my approach to getting started.

This post was in part inspired by Andrew Lin’s VTS 2 Year Retrospective

More on Security at VTS

Building VTS Blog

My Blog