We interviewed Hollis to learn more about how he and his team settled on Exago BI and leveraged it to meet their rigorous security requirements.
Please tell me about your role at FM:Systems. What sorts of tasks do you oversee as VP of Software Development?
I am currently the VP of Software Development for FM Systems. I joined the company in 2008 as a Senior Systems Designer / MS SQL DBA. In 2010, I was promoted to the VP role. In this role, I oversee the Product Management, Development, QA, IT, and Hosting Departments. In any given day, I am involved in the R&D, development, implementation, and deployment of the product through overseeing the acquisition of new hardware and regulatory compliance for the hosted solution.
FM:Systems is a FIPS 140-2 compliant technology. Why must FM:Systems comply with these regulatory standards, and what do they entail?
FIPS 140-2 is a set of certified encryption algorithm classes you can use. The government signs off on them as secure and certifies that these algorithms and classes have been certified to meet a minimum level of security for storing government data. Once you set the classes and algorithms, going forward it’s about making sure that you’re not doing anything new that introduce a non-compliant class or algorithm. The first time we went through the application start-to-finish and converted everything to be FIPS compliant, it took us between 800 and 1000 man-hours to complete.
For us, FIPS 140-2 compliance is critical for our federal clients. Without the ability to say that all components of our product are FIPS 140-2 compliant, we are unable to obtain ATO’s (Authorization to Operate) from the agency, we would be unable to pass our annual audits for NIST (National Institute of Standards and Technology) 800-53 Rev 4 compliance, and the application would simply not get authorized for use by the Information Systems Security Officer. In Windows, you can set the FIPS switch, which says that any component that calls an encryption class that’s not FIPS compliant will not get loaded. Our federal clients use that switch, so it’s important that every call has been FIPS certified so that the components will load. Without that, the application will just break.
MD5 hash functions are a good example of a non-FIPS compliant class. Everyone used to use them to store passwords, but they’re easy to reverse; you can brute force them. When we first did a scan of Exago’s code, there were a couple of places where it was using MD5 hashes, and those had to be converted to SHA-2 hashes to be compliant.
Are there any other major security requirements your BI solution has to meet outside of FIPS?
We needed it to pass Veracode Static code scanning, so that we could be sure that it was coded using best practices, with current components, and did not have security vulnerabilities within it. After that, it was critical to us that we were able to filter the tables and data that the end users could see based on their permission sets within FM:Interact®.
How does Exago differ from other BI applications you evaluated, in terms of security?
Due to the API, great documentation, and support, it was much easier to limit access and be 100% sure that you were getting what you wanted. With respect to the scanning of the code for quality and security vulnerabilities, Exago was the only vendor that did not shy away from having their code scanned. In fact, they were excited to partner in the process and guaranteed fixes with defined times. To date, they have met all SLAs (Service Level Agreements) that we initially agreed upon.
Why do you think other BI vendors shied away from having their code scanned? Wha>t’s the risk?
I think they feel that it places their code outside of their control. In letting us look inside, we’d see exactly what vulnerabilities are in there at the same time they do. Exago came up with a different approach, which was “We’re not worried about what you’ll see because we’ll fix it.” Most companies are very tight-lipped about what their vulnerabilities are, and that’s for a lot of reasons. It can hurt you in the marketplace. But the other approach is to recognize that every software application is insecure because it’s built by people. In that case, you can decide to honor your commitment to security, go in, and fix whatever problems you find. And that was the difference we saw in Exago from the different vendors we engaged.
We did find one other vendor who agreed to be scanned, but they had issues complying with our SLAs, which stipulate how long we (and any third-party software embedded in our product) have to fix any problems. They weren’t willing to entertain the prospect of being held to those SLAs.
How did deploying Exago go for your company, from a security standpoint?
We did require some customization, and we added some encryption on top of the report registration so that if something were to happen, there would be no possibility of the breach going beyond one client. We coded that on top of Exago’s web services, and it took us about 6-8 weeks working in conjunction with Exago support to get that completed, which was four months faster than we had predicted it would take!
More recently, we’ve needed support for the TLS 1.2 web format, which is currently considered the only secure HTTPS protocol since all the others have been breached. Exago just recently released a build with that new security protocol setting included.
Exago, from my perspective, has stood behind every commitment they’ve made. When we’ve had security questions, it’s never been an adversarial conversation; it’s always been a partnership. We’ve had everybody jump on, from the VPs to the developers, when we had something that we thought we found, even when it wound up being a false positive. I’ve been really impressed by the fact that security is that much in the foreground from executive management all the way to documentation, security is held to be of critical importance.