Managing OWASP Top 10 Risks
As part of our Security Program, managing risks is of utmost importance.
The OWASP Top 10 list summarizes the most common risks that affect applications, and as such it is a great starting point to demonstrate our efforts in terms of securing our solutions.
Preventing Vulnerabilities and Reducing Impact
- Some elements of our Secure SDLC are not specific to the risks below, but address security issues in general.
- Developers have access and are allowed time to participate in secure coding training. These train- ings are very pragmatic and are designed to provide hands-on experience in finding and fixing secu- rity issues in code.
- Our internal Coding Security Standards and Secure Design Principles serve as a list of security re-quirements, and provide a list of rules that all code must follow. Static scanning helps to identify weaknesses and vulnerabilities.
- Regular internal penetration tests are performed on our applications to find potential issues before code reaches production servers.
- Impact of an exploited vulnerability is reduced by implementing the principle of least privilege on every possible level of our technology stack.
OWASP Top 10 Risks
Broken Access Control
All access is authorized by our backend system based on necessary data including the caller identity, called endpoint and request parameters to prevent both vertical and horizontal privilege escalation. Access control solutions are reused where possible. API calls related to authentication are rate limited to reduce the risk of DoS and automated data harvesting.
Cryptographic Failures
Any connection between web clients or recent devices and our servers always supports TLS. This includes connections from client browsers to our web servers, but also connections from devices to our services. Plaintext protocols are not used for device communication on devices that transmit sensitive data unless it is a specific customer requirement for device communication.
Cryptographic algorithms and key strength are regularly reviewed and updated as necessary.
Data at rest in our SQL databases is stored on encrypted volumes.
Injection
As a first line of defense against injection type vulnerabilities, our web applications implement input validation. User input is validated for type and format where feasible.
Modern frameworks also provide appropriate encoding to prevent injections when creating certain objects including XML documents, which reduces the risk of such vulnerabilities.
The risk of SQL injection is further reduced significantly by the correct usage of an ORM.
The risk of OS Command Injection is also greatly reduced by the underlying Java-based technology stack where OS commands are never run from code.
Regarding XSS, we manually review our code and test environments for cross-site scripting. Some technologies and frameworks that we use help prevent XSS by applying appropriate encoding by default.
Insecure Design
Our internal Coding Security Standards and our Secure Design Principles serve as a list of security requirements, and provide a list of rules that all code and architecture must follow. When making decisions on potential improvements, we consider sources including BSIMM and SAMM. Our Security Council provides governance and oversight on security design.
Security Misconfiguration
We aim to implement the least privilege principle on all levels of our technology stack. The attack surface is also reduced by only installing necessary components. Server configuration is managed by automated solutions to ensure compliance with internal policies. Application-level configurations are also managed automatically and checked via security code review and static analysis.
For XML processing, inline DTD processing is disabled where possible, or appropriate mitigations are applied where it’s necessary.
Vulnerable and Outdated Components
We review 3rd party components and their vulnerabilities. Components with vulnerabilities are assessed, and if the vulnerability affects our services, an update or fix is scheduled according to the risk. In case of open source components, this is also supported by GitHub notifications of vulnerable components. Furthermore, we perform regular network scanning to find vulnerable services across our environments.
Identification and Authentication Failures
Our web applications require strong passwords according to NIST recommendations (NIST 800-63-3).
Accounts are locked for exponentially increasing time periods after a number of unsuccessful login attempts. Both successful and failed login attempts are logged. Password recovery is done through email, where only tokens are sent. Passwords are never sent in email. Passwords in the database are hashed with an appropriate key derivation function (not a plain cryptographic hash), using standard, well-known implementations. This prevents brute-force attacks even on a known list of password hashes.
Software and Data Integrity Failures
Our web services are updated via a trusted, reviewed CI pipeline. Third-party module vulnerabilities are checked via automation partially provided by GitHub. Devices use signed firmware updates and do not load unsigned or untrusted images. Firmware can only be signed via a rigorous, carefully designed process that adequately protects signing keys.
Insufficient Logging and Monitoring
Auditable events are logged, and logs are collected in a central repository in real time. Audit trails are available. We have application monitoring in place to detect anomalies. Logging never includes secrets, and is compliant with GDPR.
Server-Side Request Forgery
Developers are aware of SSRF, code reviews and static scanning help to prevent such issues. User input is sanitized where necessary to mitigate SSRF. It is also part of our penetration testing to specifically test for similar issues.