Client Login
It’s an old adage that security has to be built in, not bolted on. No doubt a cool sound bite, but what does it mean in practice? Here’s what I stress in conversations with customers when discussing our security strategy:
Commitment at the Core
Security is at the core of our design and starts at the outset of our development. As obvious as that may seem, it is far from the norm in the industry. Why is that? Why do many companies try to layer on security? The rub is that such a commitment to security requires a large (and unglamorous) investment of frequent design reviews, painstaking best practice implementations and expensive external audits. This deeply influences the cost of development and changes the culture of your organization. Nevertheless this commitment at the core is the only way to ensure that security is pervasive throughout the platform and not window dressing on a particular module.
Embed in the Culture
We invest heavily in training engineers on security principals. Because of the accumulated knowledge of third party audits, BoardVantage has a reservoir of knowledge, which we make sure is absorbed throughout the team. We encourage our developers to think like hackers. We create an environment where customer privacy is sacrosanct. For example, a common industry debugging practice is to log user activity to identify system anomalies or activities. It’s undeniably efficient, but it cannot be used here. At BoardVantage developers have no access to customer content because all data is always encrypted, be in transit or at rest.
Software Integrity
No matter how secure your architecture, bugs can potentially create attack vectors. That’s why BoardVantage QA is trained on the principals of software security and well-versed in sniffing out vulnerabilities that might compromise that integrity. That’s why we wrote a battery of core test cases that stress security and highlight any weak links. That’s why any changes to security architecture trigger a top-to-bottom regression test, no matter how minor developers perceive those changes to be.
Process Discipline
Do commercial pilots skip their pre-flight checklists? I don’t think so, at least, not if they want to keep their job. The same principle applies when managing a secure infrastructure. There can be no exceptions or deviations from established process. All new hires are formally screened with full background checks. Code reviews are not an option. They are at the core of our development process. Even experienced programmers benefit from other eyes examining their code. One process, somewhat unique for a service provider, but essential for integrity, is separation of duties. Engineers cannot access the data center. System administrators cannot access customer data. Third parties are contracted to perform penetration tests.
If all of the above seems a lot of effort, then you’d be right. It has been a costly and time-consuming investment for BoardVantage to develop this infrastructure and maintain it at its current high caliber. Is it worth it? For us it is. Because of this investment Fortune-100 customers trust us with their most sensitive data. Would another vendor with less rigorous security be good enough for you? That I cannot answer, but perhaps you might consider the consequences of inadvertent disclosure of your own data. What would the cost be of that?
Ethical Hacks
Wednesday, September 1st, 2010If you expect a system to perform when you need it most, you’d better test it. And it’s a fact of life that it will be a better test if it’s done by people who did not build that system in the first place. We’re not talking about manipulation here. It’s just that a fresh perspective will raise at least some areas of weakness that are otherwise inevitably overlooked. An ethical hack is such an independent test.
For a prospective customer, third party audits and a prestigious customer list will often suffice as adequate validation but in some cases there is simply no substitute for checking under the covers yourself. As CTO at BoardVantage, far from being a purely negative ‘cost-of-sale’, I welcome third party inspection. Different eyes might uncover overlooked details, and the hack itself serves as a process refresh which is difficult to accomplish with just internal staff
An ethical hack is usually performed either by the information security team of an F-100 or financial institution, the IT department of a smaller organization, or a third party specialist. Because in commercial SaaS environments, the production system is in use 24×7, the ethical hack is ALWAYS performed against a mirror system. That way you obviate the (slim) possibility of customer data being compromised or bring about potential performance deterioration during DoS (Denial of Service) testing.
It is much easier to talk the talk on security than walk the walk but an ethical hack will quickly separate the vendors who fall in the former group from the ones who have made the costly investments and who fall in the latter. So, if a vendor is serious about security, ethical hacks are a wonderful source of customer feedback. Third parties, immune from internal politics, can make observations that might be difficult for internal QA departments and security teams. By subjecting oneself to a plethora of different tests by different teams, the vendor dramatically increases the coverage of possible exposures.
While an expensive investment for both customers and vendors, ethical hacks remain the most effective way to verify the security of any SaaS vendor. In addition ethical hacks remain one of the best ways for a vendor to assure that the systems meet the standards and that the vendor’s standards are in fact up-to-date.
Posted in Collaboration Benefits, Industry Comment | No Comments »