Application Security & Secure Development
Threat Modeling
Every in-house development as well as outsourcing projects starts with security requirements.We support you in defining appropriate and individual security requirements for your applications. This can be relevant for in-house development as well as for an externally outsourced development and belongs in every requirement and functional specification as well as in the contractual design.
Threat modeling according to STRIDE is a method for threat analysis to identify risks and attack vectors. First, the application landscape including the underlying IT infrastructure is modeled with the element types process, data storage, data flow, external entity, and trust boundary. This can be done technically and on several hierarchical levels or in a use-case/misuse-case-oriented manner. The threats are then mapped to the entire data flow diagram according to STRIDE and specified in the technological context, and subthreats are generated (e.g., threat spoofing (the first S of STRIDE) by means of the password bruteforcing attack during login).
The goal of threat modeling is to define mitigation measures and thus enrich the architecture with security measures. In this example, CAPTCHAs and throttling at login are used. Threat Modeling as a whole is an excellent method to systematically and completely identify and secure all risks of an application architecture and IT landscape. Without threat modeling, it is almost impossible for a security architect to identify ALL risks and to take measures; in this case, only past experience is used and measures are only incompletely placed.
STRIDE categorization of threats
- Spoofing: The attacker spoofs a user / system / process, etc., thus impersonating another entity. Mitigation measures of the authentication category
- Tampering: The attacker manipulates a data flow, data, process, etc. Mitigation measures of the category encryption / integrity check / input validation
- Repudiation: The attacker performs his actions unnoticed. Measures in the Logging, Monitoring, Intrusion Detection Category
- Information Disclosure: The attacker gains unauthorized access to sensitive information. Extensive measures necessary, such as secure error handling, encryption, hardening
- Denial-of-Service: The attacker takes down the system. Extensive measures necessary, such as hardening, DDoS protection mechanisms, secure programming
- Elevation-of-Privilege: The attacker gains more rights than he is actually entitled to. Measures in the Authorization Category According to the Least Privilege Principle
Application possibilities
- Risk analysis according to ISO 27001 / ISO 27034
- Analysis of a (cloud-based) application architecture
- Capture of attack vectors and support in defining the scope of a penetration test
- Cloud migration projects
Secure Source Code Review
As part of the security code review, an automated and a manual security source code review are performed for security-relevant areas to identify security vulnerabilities.
The automated test is not restricted and is performed over the entire code. A manual review is performed on both the findings from the automated tests to identify and exclude false positives and on security critical code locations of the application.Results are performed.
- Automated code reviews
- Quality assurance of findings, exclusion of false positives
- Manual code reviews on security-critical code passages
Automatic Security Code Review
First, the software is onboarded into suitable security code scanners. The scans are then started, followed by the evaluation and cleanup of the results. It is important that the code is delivered in build-capable projects, as otherwise considerable additional effort can be incurred during onboarding. Here, the support of an experienced buildmaster from the customer may be required.
The scanners used are currently considered the standard for automatic security checks of source code. They deliver good to very good performance in finding simple technical security vulnerabilities. Unfortunately, the evaluation of the severity of a finding is often incorrect. Highly rated findings often turn out to be low severity findings on closer inspection and vice versa. However, the detection rate in the area of complex or technical security vulnerabilities (e.g. authorization assignment during login) is significantly worse than for technical security vulnerabilities (e.g. use of vulnerable methods). The automatically determined security vulnerabilities are therefore quality-assured and cleansed of false positives. In the meantime, a manual review is already carried out, as the code areas around the automatic findings are also considered manually.
Manual Security Code Review
As part of the manual security code review, selected security-related code areas are manually reviewed according to the international CWE standard to identify typical implementation errors such as the following:
- Input validation (Blacklisting/Whitelisting)
- SQL-Injection
- OS-Command Injection
- Buffer Overflow
- Cross-Site-Scripting
- Strong Authentication
- Use of Cyptography
- Access Control
- Unrestricted Upload
- Cross-Site Request Forgery
- Error Handling
- Denial-of-Service
- Information Disclosure
- Open Redirect
- Path Traversal
Manual and Automatic Dependency Check
As part of the dependency check, all third-party components used (third-party libraries) are checked for a version status and, in particular, for security vulnerabilities (CVEs) contained or published. In order for this test to be carried out completely, all libraries must either be available in the repository or corresponding build files must be available, which use the third-party libraries used and their versions during the build.
Since not all security vulnerabilities and security fixes are contained in public vulnerability databases, a manual dependency check is also performed and changelogs and commits are checked for security fixes as part of this.
Establish secure CI/CD pipelines according to the DevSecOps paradigm.
Even before the actual software development begins, it is important to develop a secure architecture that incorporates threats and their protection. During development, security should then be integrated into the complete development process, with Insentis also supporting the use of modern practices such as DevSecOps and secure CI/CD pipelines. In addition, we support you by performing dependency checks of third-party code to ensure that third-party libraries you use do not introduce security vulnerabilities into your software and perform a review of your code to quickly identify security vulnerabilities before they become a threat. Also, if you are interested in container solutions as part of agile software development with rapid deployment, e.g. using Docker or Kubernetes, we offer to scan your containers and help you deploy them securely according to best practices later on.
- Scanning & securing container solutions (Kubernetes, Docker, Openshift).
- Hardening of development & deployment environments using CIS benchmarks
- Scanning & Monitoring (CVE Monitoring, Dependency & Vulnerability Scanning, Vulnerability Management)
- Security in IaC & Compliance as Code (Terraform, AWS CloudFormation)
- Application penetration testing to verify secure coding standards, such as OWASP ASVS, MSVS, and more.
- Establishment of a Secure Software Development Life Cycle (SSDLC)
Secure Coding Guidelines
We will gladly offer the creation of development guidelines for secure state-of-the-art software development. We create these on the basis of a workshop with you (e.g. head of IT, ISB, architects, developers) to record the frameworks, technologies and programming languages you use. The results are customized and comprehensive development guidelines.
Basically, we follow international standards such as OWASP Top10, OWASP ASVS, CWE as well as best practices in the technologies used. In addition, we use our expertise to critically review, complement and orchestrate the recommendations, avoiding redundancies among other things.
First, we create generic development guidelines with the help of the CWE standard. Based on these generic development guidelines, we then derive specific development guidelines and best practices that are dependent on the frameworks, technologies and programming languages, whereby configurational aspects are also added here, which have secure operation or secure deployment as their goal in the context of DevSecOps.
