Process
Do you follow Agile or DevOps practices?
Agile / DevOps practices help eliminate paths to project failure. Also, DevOps is a proven paradigm to increase the speed, efficiency and quality of software delivery as well as improving staff morale and motivation. It’s recommended to follow DevOps methodologies when building software where possible. Do you follow an approved development and operations path?
Development and operations processes should be normalized, and reviewed to ensure the right level of security is applied throughout. Policies, standand, and governance should be incorporated and automated where possible.Do you provide security training to your employees periodically?
Training should be a foundational component of any security program to enable team members with the knowledge to understand, identify, and avoid security issues. Dev or Ops team members cannot be expected to know which security threats exist or what to do about them. Training informs the staff as to what the organization considers risky or acceptable, what to look when identifying threats, and how to address them. It is recommended to provide security training to Dev and Ops team members at least once a year. This should include OWASP Top 10 and threat modelling training at a minumum. Additional training can focus on areas where the team produce the most security vulnerabilities.Is the communication transparent and prompt across the team?
Not having a transparent and prompt conversation is an imporant factor that a team should have in order to solve bugs and it is expected from all team members to have that.Inception
Do you use a distributed version control system for your source code?
In case of having complex vulnerabilities maybe multiple developers are involved, we need to be able to track down the reason of those vulnerabilities easily by have a good team collaboration.
Do you perform an initial security risk assessment before proceeding to development phases ?
Risk assessment is a process to identify issues that can harm the business and the associated impact as well as likelihood. This involves performing a Business Impact Assessment (BIA) to identify sensitive data and business functions, potential attackers, impact from an attack, and performing threat modelling to determine various ways the attacks can be realized. This will help focus the organization’s limited time and resources on where it matters most based on business risk. It is recommended to perform an initial risk assessment during inception to ensure key risks are identified and addressed appropriately during development. Threat modelling and risk assessment should be an on-going process throughout the application lifecycle.
Do you plan for use of the right security automation tools at different stages of Dev and Ops?
Automated security scanners can easily find the low hanging fruit, requiring no effort from team members. In addition, oftentimes finding a security issue is similar to finding a needle in a haystack, and automation eases this process resutling in a more secure product. It is recommended to run automated Static Application Security Testing (SAST), Software Composition Analysis (SCA) / Vulnerable Dependency Checking (VDC), and Dynamic Application Security Testing (DAST) on your application at least once prior to each release.
Do you define and follow security requirements based on application’s risk profile?
Requirements describe a system, what it should do and what to expect. Defining security requirements is important as it helps design and build the appropriate level of security into the application, its infrastructure, and operations. Security requirements must be clear and easily integrated into the full process. OWASP’s ASVS L1 should be used at a minimum when building applications, and CIS benchmarks for related infrastructure.
Do you perform testing based on security requirments?
Security requirement should be tested to avoid potential vulnerabilities due to missing controls or incorrect implementations. The method and frequency of testing should be based on risk, maintaining delivery speed, and planned for at project inception.
Is there a designated Security Champion in the DevOps team?
The Security Champions can act as the primary go-to security point within the DevOps team. This can be any team member who has interest in security or some pervious security knowledge/experience. Appropriatae training and support from Security SMEs should be provided.
Responsibilities should be clearly defined and agreed to. The typical Security Champion handles the followoing: a) on-going threat modelling including identifying evil user stories, b) roll-out of security process and automation technologies, c) triage and risk assessment of security issues identified, d) acting as a liaison between AppSec SME and team members, and e) identifying areas of security improvement.
Is the Security Champion performing all assigned responsibilities?
The Security Champion is responible for conducting all assigned tasks. Effectiveness should be measured through periodic evaluations. Planning
Do you prioritize security work items from the backlog to add to sprints?
Considering security requirements (work items) for inclusion in each sprint is an important factor in reducing risks associated with the vulnerable application code.
Do you review backlog items and identify those with potential security impact?
While planning for a sprint, backlog of work items shoud be reviewed to identify those that handle sensitive data or functionality where comprimise could adversly affect the system. These work items should be tagged so they can go through a security review.Dev/Design
Do you perform security review and risk assessment on key changes to the design?
Security reviews are an important aspect application security and should be performed to gain an understanding of risks facing the system. Anytime components, datastores, interfaces, or functions of the application are modified, a security design review should be conducted and risks should be identified in order to take the correct mitigating action.
Do you consider abuse cases during design and assess security risks?
In addition to considering the “happy path” of user stories and requirements, “evil user stories” or “abuse cases” should be investigated to understand and account for potential weaknesses in the application. Addressing these issues during design can prevent costly fixes after the product has been deployed.Dev/Code
Do you use security plugins in your IDE?
In addition to considering the “happy path” of user stories and requirements, “evil user stories” or “abuse cases” should be investigated to understand and account for potential weaknesses in the application. Addressing these issues during design can prevent costly fixes after the product has been deployed.
Do you perform static analysis before accepting code from developers?
Static application security testing is used to secure software by reviewing the source code of the software to identify sources of vulnerabilities. It is recommended to enforce this on all pull requests, however an initial scan should be conducted to create an expected baseline.
Do you scan for vulnerable dependencies before accepting code from developers?
Using software composition analysis (SCA) vulnerable dependency checkers (VDC) on pull requests is important since many applications use open source libraries that can contain vulnerablities. It is recommended to enforce this as a gate on all pull requests, however an initial scan should be conducted to create an expected baseline. Given the rise of dependencies as an attack vector, this control should be prioritized to ensure continuous vulnerability detection is in place.
Do you block on a failure of a security scanner in the build pipeline?
It’s important to block the pipeline when a vulnerability is detected. Threshold should be configured based on risk appettite (High risk issues should always block the build). Fixing all issues is preferred where possible, otherwide risk acceprtance should take place and the issue should be captured in the appropriate risk traking system along with the risk level.Dev/Integration
Do you run automated dynamic testing against the running application as part of deployment?
Dynamic application security testing (DAST) allows interaction with the live application to find vulnerabilities that can only be uncovered while the application is running. This type of testing can take longer than static testing methods and should not be a blocker of the pipeline. Static analysis should also be performed, along with container scanning (if applicable) at this stage. An initial scan should be conducted to create an expected baseline.Release/Deployment
Do you perform threat modelling to identify possible gaps during release/deployment phases?
Prior to release, current design of the application should go through threat modelling to ensure no additional risks have neen introduced during sprints leading up to the release. Design changes often take place during agile development that may not be considered during user story reviews since such changes often require consideration from end-to-end perspective.
Do you conduct manual testing of requirements not covered by automation at least annually?
Automated tools and online scans are unable to complete more than half of the required test cases without human assistance. If comprehensive test automation for each build is required, then a combination of custom unit and integration tests, along with build initiated online scans are used. Business logic flaws and access control testing is only possible using human assistance. These should be turned into unit and integration tests.
Do you perform automated SSL/TLS scanning?
All data in transit should be encrypted using TLS ciphers that are not deprecated to avoid breached. A tool such as SSLyze can be used to perform this,
Do you perform automated infrastructure and platform scanning?
Performing automated infrastructure and platform hardening tests are important to find network-related flaws, and should be considered as an important step in the CI/CD pipeline.Operations/Monitoring
Do you add live detection and protection capabilities such as IAST or RASP?
Although SAST, SCA/VDC, and DAST are important, they do not have a inside view or context of the application. IAST and RASP tools use agents inside the appliation to performs similar functions as SAST/DAST, and a WAF repsectively. This inside view and use of live instrumentation provides lower false positives and more accurate identification of vulneravilities.
Do you use a Web Application Firewall (WAF) to protect your applications?
Having a web application firewall (WAF) in place is recommended as the team may not be able to find all possible vulnerabilities in the application. WAF can create an extra layer of protection, but it is not a replacement for hardening the application through secure design.
Do you maintain an up-to-date threat model and incident detection use-cases?
It is important to keep the application threat model up-to-date to have an accurate risk view as the architecture changes. Detective controls should be considered when performing threat modeling (at least annually) from an operational perspective while considering the current threat landscape as well as incidents that took place since the last assessment.
Do you determine areas for security improvement and add to backlog?
Security results from the various proccesses and tools incorporated in the DevOps practices should be reviwed at least annually, and work items should be added to the backlog along with risk levels.
Do you provide training to team members in order to target areas of weakness identified?
Targeted training should be provided to address specific areas of weakness identified during the various security activities. This is important to ensure the team does not introduce the same vulneabilities time and time again, and efforts are focused on where actual vulerabilities exist.
Do you send logs from the application and infrastructure to a central monitoring platform?
Without end-to-end logging and monitoring that includes application as well as infrastructure-level security event logs, reconnaissance and breaches will go unnoticed. It has been shown that the longer an attacker is allowed to perform reconnaissance activities, the higher their likelihood of success.