- To understand PolicyStat's security strategy
The purpose of this document is to provide transparency into the processes PolicyStat has in place to keep our customers’ data secure. This is primarily a technical document targeted at IT Professionals evaluating PolicyStat’s application security.
Securely developing, maintaining and delivering a web application over the Internet is a multi-faceted task that we approach in a methodical, process-first manner. To support a layered security strategy, we combine rigorous change control processes with continuous improvement driven by root cause analysis. We believe that effective security is only possible when it is integrated into every step of the application life cycle, from design to implementation to maintenance and monitoring.
At the application level, every single change we make (in accordance with the PolicyStat Update Process) goes through a peer review process where at least one other engineer (separate from the primary author) both reviews the changed code and evaluates the change for performance, quality, usability and security. We employ checklists for both the author and the reviewer to ensure consistent compliance with that process.
Mitigation of the OWASP Top 10¶
The Open Web Application Security Project (OWASP) is an international community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. They regularly publish an OWASP Top 10 list of the most critical vulnerabilities commonly found in web applications, along with mitigation strategies and advice. PolicyStat has specific tools and processes in place to mitigate or eliminate the potential for each of the Top 10.
At the infrastructure/operational level, we are strict adherents to the “infrastructure as code” principle and all infrastructure and operational changes are codified in source-controlled API calls and configuration files. This allows us to employ largely the same peer review process for infrastructure as we do for application changes, specifically testing for security, scalability, performance, etc. By implementing testing environments that are almost identical to our production environment, we support operational penetration testing as part of our normal change control process.
Limited Attack Surface¶
By very consciously limiting our exposed services to HTTP connections forced over SSL (HTTPS) through a single load balancer plus locked-down SSH access, we’re able to reduce the number of possible attack vectors.
Like any modern web application vendor, we rely on many pieces of infrastructure software below our application, from operating systems to web servers to databases. In addition to regular roll outs of security updates, we actively monitor security mailing lists for our tools in order to make quick decisions about any necessary out-of-band updates. For example, we were able to employ a test for the Heartbleed vulnerability on the day of its public disclosure.
At the data center level, we partner with a world leader in security and compliance. From physical access control to background checks to external audits, the AWS Security Whitepaper provides deep detail into the effort undertaken to ensure the physical security of our systems.
Tight control over authentication methods is crucial to security at all levels. We employ the following strategies:
- Strong SSH Keys: All SSH sessions require access via SSH keys. Password-based access is disabled and SSH keys are not shared between individuals.
- Multi-Factor Authentication: We utilize AWS’s MFA capabilities for all accounts. This includes our root account and the individual IAM account for each operations team member.
- Partitioned API keys: In addition to being given the least privilege possible, API keys are partitioned at both the machine level and the individual level.
On the non-engineering side, security also matters. Our internal policies and process ensure that employees are trained in and implement security best practices like:
- Phishing awareness
- On-disk encryption
- Strong passwords
- Principle of minimal required privilege
- Regular access audits
- Two-factor authentication