We believe in security by design. It should not be an afterthought. It should permeate all aspects of the software lifecycle from architecture and design, through implementation and QA, to production, and it must be carried on in updates and maintenance. IronCore is committed to best practices across our organization.
Our business is built around the use of cryptography to provide provable security for your data. It is essential that we provide strong cryptography that you can trust.
In order to provide this security in a scalable environment, we implemented a type of encryption called transform cryptography (also known as proxy re-encryption). We selected an algorithm that had been introduced and evaluated in multiple peer-reviewed academic publications, and we recently published a paper describing our use of transform cryptography that also went through a peer review by cryptographers and was presented at an academic conference. We have done presentations on our cryptography and our implementation to professional developer and security conferences, including a presentation at the Crypto & Privacy Village at DefCon 2018. Trustworthy cryptographic software requires scrutiny and transparency. In addition to gathering input from the cryptographic community, we engaged the NCC Group to conduct an audit of our transform cryptography implementation. We quickly resolved the issues that they discovered and they confirmed our changes. They are preparing a public report on their findings now. We welcome any and all inspection of our core cryptography code. We created an open source project containing our Scala implementation of the transform cryptography library – anyone can browse or clone the GitHub repository IronCoreLabs/recrypt and submit issues. Better yet, we have created a Bug Bounty program to reward anyone that uncovers a bug in our system and responsibly reports it to us.
We are very opinionated about what constitutes good software. We’re craftspeople building solid and reliable software using functional programming paradigms that rely on mathematical principles to make software more testable, understandable, and less prone to unforeseen and unhandled errors. Contrast this to the outdated software underlying many existing security libraries. We build for security and reliability.
We use a variant of Microsoft’s Secure Development Lifecycle as part of our Engineering practice. We are strong proponents of test-driven development and the use of continuous integration to guarantee that we are doing as much as possible to root out errors early in the development process. We build property-based tests and utilize random inputs for unit tests to avoid missing errors due to preconceptions. Our code management policies require peer review of all code and mandate a high level of unit test coverage. Tools to check for compliance with coding standards are integrated into our build process. We regularly run static code analysis tools on the code base to search for security problems.
To ensure the integrity of our software over time, we have automated integration and regression test suites that are run when we integrate features into our code base. We also execute regular penetration tests on our systems, scanning for vulnerabilities in the software and the infrastructure.
Our engineers are trained in the principles of secure design and coding, and we require all engineering staff to refresh their training on these important aspects of their jobs annually. The information covered includes the OWASP and SEI CERT secure coding practices, along with other design and programming guidelines.
In spite of our best efforts, software defects are an unavoidable occurrence in even moderately complex systems. Bugs are a reality and will be found in our code as well as in the stacks we use, from libraries to operating systems. We believe that the policies and procedures a company implements to locate, isolate, and respond to these issues are as fundamental to security as any other practice or deployed security technology. We have a well-defined process for reporting, prioritizing, and tracking bugs, with separate categorization for security-related issues. Our release processes include separate procedures for releasing hot fixes to patch critical and severe problems. All manifestations of bugs are incorporated into unit, integration, and regression tests to guarantee that once they are fixed, they stay that way.
The infrastructure that runs our services was also designed with security in mind. The measures we utilize to protect our interface to the Internet include the following:
We require that our operations staff follow stringent authentication requirements, including the use of two factor authentication, to access our infrastructure.
We also require the use of encryption within the infrastructure, as explained in the next section.
Even though the data we are handling is secured using end-to-end encryption, we utilize defense in depth techniques to further protect everything. We use encryption in transit to maintain the confidentiality of any metadata associated with interactions with our APIs, and to guarantee that clients are talking to our APIs, not an imposter. Our infrastructure uses encryption in transit as well, providing extra layers of security even inside the firewalls that protect it from the threats roaming the Internet. We use encryption at rest to add extra security to data and its related metadata once it is stored on our servers. Backups are encrypted before being moved to cold storage.
We welcome and invite responsibly disclosed vulnerability reports. We'll work hard to respond to these quickly and to give you recognition and, in some cases, awards for letting us know what you found. For program details and submission instructions, visit our Bug Bounty program page. To see our disclosures and recognition, visit our Security Advisories page.
How do you prove security practices? Security is about using Defense in Depth, using multiple layers of various types of defensive measures to protect source code, data, and customer assets. It needs to be measured with a comprehensive and detailed analysis of a company’s operations and practices.
SOC 2 is an audit, conducted by a trusted third party and standardized by the American Institute of CPAs, that is specifically designed to be that comprehensive analysis. IronCore Labs welcomes this kind of detailed look at our security practices, and that’s why we have gone through the rigorous process and achieved SOC 2 certification for Security. Our SOC2 Type 1 audit was conducted by Coalfire Systems https://www.coalfire.com/ a respected cybersecurity services company.