Our Approach to Enterprise Security

A Q&A with FiscalNote’s Sr. Director of Info Security Ken Kantzer

Why is it important for software companies to have an on-staff security director?

KK: A lot of my job as a security director at FiscalNote touches a lot of different aspects of security across the company. It’s not just about looking at the technical security of our products — it’s looking at our processes, our risk management process, and our governance. There’s a broad spectrum of security considerations I’ve been able to add extra focus to — whereas before, those things weren’t handled by anyone specifically.

As an on-staff security director, I’ve been able to add some balance to our security program and focus on aspects of our company that will strengthen our overall security posture, not just our technical security.

Additionally, it’s really important to have a very clear security point of contact internally and externally for your company. I meet with customers and prospects quite often to help understand their particular security requirements and how our product meets it. I think that’s pretty crucial. Also, having someone who’s able to interface with security researchers and engage with them is quite important.

How can companies make remote work secure?

KK: I think the human side of this gets overlooked pretty often. Especially when it comes to mitigating things like phishing attempts. A lot of phishing techniques are meant to take advantage of gaps in trust or gaps in communication between staff: and it’s exactly those gaps that tend to form during periods of remote work.

A classic example of this comes from back when I was leading penetration-tests. We would always send our spear-phishing attempts on the weekends. The reason why is because if you send it to four or five people during the workday, they’re all sitting next to each other in the office. It’s much easier to turn over to the guy next to you and ask, “Hey, did you get this suspicious email?” and discuss the situation. Whereas if you’re by yourself, for example, on a Saturday, you don’t have that support and very direct line of communication with someone next to you.

Unfortunately, that same dynamic applies to remote work all the time, not just during weekdays. This is a central challenge, I think. This is where an on-staff security director and team can also make a big difference.

What I’ve been doing at FiscalNote to combat this is emphasizing our security team as a friendly, approachable resource and presence that they can come to with questions about suspicious behaviors and activity. We’re making the team and the method of communication as visible and accessible as possible for the rest of the company.

Which key security metrics and benchmarks should software companies care about?

KK: A key metric is time to remediation. Meaning, when you discover a piece of outdated software or another bug in your software, how quickly does it take to fix that and have that fix released to production? That’s often a very good metric of your software company’s understanding of security needs and concerns, and then also the flexibility of the software teams and product teams to be able to quickly make adjustments there.

In terms of benchmarks, the most important thing is that you are benchmarking yourself externally on a regular basis. It comes back to external penetration tests. It’s extremely important to have external eyes on your processes and security controls — and the underlying software and products you’re producing.

That’s the benchmark that you should be expecting from your vendor and also as a vendor, that’s the benchmark that you should really be focused on. This ties together with the SOC 2 certification.

Every year, for SOC 2, we have to go through a full audit of our controls. They analyze the last period’s data and determine if we met the standard. It’s a very involved, rigorous process. Our public report that we send to our clients and prospects has that analysis, so our clients know exactly where we stand in terms of how we’re meeting those controls.

When it comes to evaluating enterprise security, what is SOC 2 and why is it important?

KK: SOC 2 provides external proof that a company’s systems and its security have received an independent, third-party review and have followed specific security guidelines. For a SOC 2, Type II report to be granted, a third-party auditor will collect evidence of your security processes over a specific length of time. They then validate that all necessary security controls are in place and operating effectively during this period.

So, in the same way that your company might do a Sarbanes-Oxley financial review, this is a type of audit conducted to prove that your security is up to snuff.

Right now, SOC 2 is the highest quality external proof that you can provide to your customers who are concerned about putting their data on your platform. While some of the SOC 2 requirements resemble those of other security frameworks, such as NIST 800-53 or ISO 27001, SOC 2 is unique because it is rapidly becoming a must-have certification for U.S.-based SaaS companies that store customer data.

What is SAML and why is it important?

KK: SAML — Security Assertion Markup Language — is an authentication standard that allows you to manage log-ins to an external website or web application using your own in-house authentication and identity management tool (that’d be something like Active Directory or Google Suite).

There’s been an explosion of new enterprise software entering the market (and in particular SaaS, cloud-based products). Companies need to adopt these tools in order to continue to be competitive and create new value. However, controlling access to these cloud products is complex. You have to keep long lists of all the cloud software your company is using — and when someone leaves your organization, you have to remember to remove them from all the platforms to keep your data safe.

Once a company has reached a size where it’s no longer feasible to manage individual off-boarding per SaaS app, it will turn to things like SAML as a requirement for any additional SaaS products the company purchases. This allows them to maintain centralized management of users and do secure on-boarding and off-boarding.

Another advantage: SAML allows you to hook into Office 365 or Google Suite’s own log-in security mechanisms, which oftentimes represents the most secure log-in mechanisms that exist online. This allows all your SaaS products to reap the advantages you get with Office 365 or Google Suite’s advanced security features.

Let’s say, for example, you roll out two-factor authentication within your organization. What if your SaaS products don’t have it? What if it’s left up to the individual user to decide to turn that on or off? If your SaaS product is connected to SAML, it uses and leverages the fact that your main G-Suite or Microsoft provider is using two-factor; so, you’re able to centralize your identity management.

On the flip side of this, there are a lot of benefits for SaaS companies to adopt SAML as more and more companies are making it a requirement. Adopting SAML allows clients to feel more confident when adopting your tool and also gives them a feeling of greater integration with your software platform.

What questions should customers ask their software vendors when it comes to security?

KK: I think a customer should ask — almost right off the bat — if the SaaS provider is SOC 2 compliant. It’s a big tell. There’s a lot of ambiguity over this and oftentimes, for example, you need to ask clarifying questions because the sales team of a SaaS product might give you the report of the underlying data center that they use (for example: if they’re on AWS, they may give you Amazon’s SOC report). If you ask, “are you SOC 2 compliant?” and the vendor says “yes, our data center is,” that’s not the same thing as their product line being SOC 2 complaint. This is really important. In the past, I’ve received a SOC 2 report that is not the report for the company, but rather the report of Amazon or some other data center provider — and that’s a big distinction.

Other critical factors include the frequency and quality of the outside penetration tests that have been conducted. Any good security program should be conducting regular penetration tests. Some vendors are particularly sensitive about sharing these test results, but I feel like the industry is moving toward vendors being more transparent about sharing these results. The reason why it’s crucial to see these reports is that the quality of penetration tests can vary significantly. Sometimes penetration tests are little more than automatic scans with a few custom sentences attached. So, again, asking follow-up questions is very important. Oftentimes, if I asked to see the penetration test report, what I get is a very generic vulnerability scan of a network and those are two very different things.

What are some of the key cybersecurity best practices for a software company right now?

KK: The presence of two-factor authentication and the move to make this a requirement instead of an option. Additionally, a best practice within two-factor authentication is moving from SMS text messages towards authentication apps or hardware tokens like Yubikeys. I think viewing two-factor as not-optional has been a key shift in the industry even within the last two or three years.

Another best practice I’ll mention is “Zero Trust.” It’s a relatively new term but it’s starting to take off — and there’s a good reason for it. What it means: you aren’t relying on the network that you’re part of in order to determine whether or not you should get access to a system. For example, moving away from VPNs as a trusted place where you get tons of unrestricted access to things, and instead moving to a world where you access servers depending on other, stronger credentials and forms of authentication.

What recovery arrangements should software companies have in place to successfully respond in the event of an IT infrastructure incident?

KK: Devise a clear Incident Response Plan and rehearse it on a regular basis.

At FiscalNote, we’ve actually combined our security incident response documentation with our normal software incident response documentation. By combining those two, we get to hook into another process that people are already familiar with, and that gets tested more often. That’s crucial in understanding who the players are when something bad happens because — when it does — the last thing you want is to spend time figuring out who should be involved.

Something else we’re looking at is actually running a series of war games where we bring the senior leadership together to present a scenario and work through our security response plan. Then, we do a retrospective to see how that went, where we could improve, whether we made the right decisions, etc.

What does the future of security look like?

KK: The future of security is all about finding ways to manage the explosive, exponential increase in the complexity of the systems you’re responsible for protecting. For example, how do you deal with the explosion of SaaS providers and tools that your company invariably needs to use and leverage in order to provide value and stay competitive? That’s not something you want to fight a battle against, in my opinion, at least. I think that’s like the equivalent to an ostrich putting its head underground and ignoring the fact that things are going to get more complex, whether we want them to or not.

A lot of what I’ve been trying to do with our security program is to fight complexity with automation. How can we transfer security tasks from something manual to something automatic?

Our team should be triaging exceptions and anomalies, not logs. Logs grow exponentially with the number of systems you have. If your job is to comb through logs daily, figuring out exceptions along the way, you’re going to become swiftly overwhelmed. The ultimate goal: bring your automation to bear on that — so you’re only analyzing things when they go wrong and bubbling up.