devopsy.kinsta.cloud

Tag: pentesting

Elevating DevOps Security: Why Integrating Threat Modeling Transforms Pentesting
Penetration testing (pentesting) has long been a cornerstone of security practices, particularly for meeting compliance requirements. However, a recent conversation with a client revealed a crucial gap in this approach. Critical vulnerabilities — particularly in their APIs and third-party software — remained unaddressed despite passing their pentest. While the pentest checked the compliance box, it did not account for the real world, evolving threats their system faced.

Although compliance-driven tests serve their purpose, they often leave organizations exposed to risks such as API abuse, supply chain vulnerabilities and insider threats. Many organizations treat pentesting as a routine task, missing out on a broader strategy to defend against the ever-changing threats.

Where Traditional Pentests Fall Short in a DevOps Environment

The compliance-driven pen tests tend to follow static checklists. This approach often overlooks the dynamic nature of modern infrastructures, especially in environments with rapid deployments, cloud services and third-party integrations. These tests may not adapt quickly enough to the new risks that emerge as the systems evolve.

For example, vulnerabilities in open-source components or dependencies in the software supply chain often go undetected in traditional pentests. This can create a false sense of security — your system may pass compliance, but still be vulnerable to real-world attacks.

Threat Modeling: A Shift Toward Risk-Based Testing

Integrating threat modeling into your security strategy offers a more tailored, risk-focused approach. Instead of asking ‘What is vulnerable’, threat modeling shifts the focus to ‘What could go wrong’ and ‘How could an attacker exploit this system’. This proactive method aligns with the fast-paced, iterative nature of DevOps, helping in identifying risks earlier in the development cycle.

In a recent case, we worked with a cloud-based company that had passed several pentests but was concerned about their API security. Through threat modeling, we uncovered a critical vulnerability in their session handling that previous tests had missed. The company mitigated a serious security risk by addressing this issue early before it could be exploited.

Optimizing Resources with Targeted Testing

One of the key benefits of integrating threat modeling with pentesting is the ability to focus resources where they matter the most. For DevOps teams managing fast-moving pipelines, threat modeling ensures that pentesting efforts are concentrated on high-risk areas rather than spread thin across the entire system.

For instance, consider a cloud infrastructure security test that used a threat modeling framework to target identity management. The test revealed vulnerabilities related to privilege escalation that a broad, compliance-focused pentest might have missed. This targeted approach allowed the team to resolve the issues quickly, reducing risk without overextending resources.

How to Integrate Threat Modeling Into Your DevOps Workflow

To make pentesting more effective and align security with your DevOps processes, consider integrating threat modeling into your workflow. Here are four actionable steps to get started:
1. Adopt a Threat Modeling Framework
  Use frameworks like STRIDE or PASTA to structure your threat modeling efforts. These frameworks help prioritize the attack vectors specific to your environment, allowing you to focus on the highest risks.
2. Automate the Threat Modeling Process
  In fast-paced DevOps environments, automation is essential. Automating threat modeling ensures that the models evolve as your system changes, continuously identifying the potential risks and updating security practices. This prevents critical vulnerabilities from being overlooked as development progresses.
3. Embed Threat Modeling in CI/CD Pipelines
  To align security with DevOps, threat modeling should be embedded into your CI/CD pipeline. This allows teams to catch vulnerabilities early before they reach production. Integrating threat modeling into build and deployment processes ensures that the security is proactive, not reactive.
4. Foster Cross-Team Collaboration
  Threat modeling should involve more than just security professionals. Developers, architects and operations teams must collaborate to ensure the threat model reflects the system’s architecture and business needs. This cross-functional approach creates a holistic view of potential risks and strengthens your defenses.
Case Study: Threat Modeling for Cloud Security

A healthcare provider applied the STRIDE methodology to their cloud infrastructure, focusing specifically on identity management and session handling. By using this threat modeling framework, they identified vulnerabilities related to privilege escalation that the previous pentests had missed. This allowed the team to prioritize their pentesting efforts on the critical areas, ensuring that these vulnerabilities were resolved before the attackers could exploit them.

Why Threat-Driven Testing is Essential for DevOps

The future of pentesting in DevOps lies in shifting from compliance-focused to threat-driven approaches. By aligning testing with real-world risks, organizations can move beyond a static checklist and address the actual threats they face. This approach offers a more holistic and adaptable security strategy.

The DevOps teams can combine threat modeling with red team exercises and adversary simulations to test their defenses against sophisticated attack scenarios. These simulations emulate real-world adversaries, allowing the organizations to see how they would fare against insider threats or advanced persistent threats (APTs). This level of testing, driven by identified risks, ensures that your security posture can evolve as your system evolves.

Conclusion: Moving Beyond Compliance for Stronger Security

Relying solely on compliance-driven pentesting is no longer enough to safeguard modern, fast-moving DevOps environments. To stay ahead of the evolving threats, organizations need to integrate threat modeling into their security strategies. This approach goes beyond checking boxes — it enables teams to identify the most critical risks and address them proactively.

By adopting structured threat modeling frameworks, automating the process and embedding it into CI/CD pipelines, the DevOps teams can ensure that security is an ongoing, integral part of their workflow. Collaboration across teams further ensures that the security model aligns with both the system architecture and operational goals.

As attackers continuously evolve their tactics, your testing strategies must evolve too. Do not stop at compliance — embrace threat-driven pentesting and build a security posture that is ready for the real-world threats your organization faces.
October 2, 2024
Leveraging Automation for Secure, Cost-Effective Mobile App Delivery

As businesses mobilize their customers and employees, they need to develop innovative mobile applications that safeguard user trust. But secure mobile development and manual security testing can be expensive and time-consuming—a bigger challenge in slowing economies. However, the latest innovations in security automation for mobile teams can drive down security costs by half while speeding release time, getting quality mobile apps to market faster to grow revenue faster.

With mobile dominating all digital time spent online versus the web, businesses cannot compromise the safety of their mobile users and mobile data. Security automation integrated throughout the development process empowers developer, QA and security teams’ efficiency, enabling faster release cycles with built-in security. This approach powers success for digitally enabled businesses that depend on mobile apps to generate revenue, engage customers and tap new markets.

A single security vulnerability within a mobile app can instantly damage a business’s financial stability, brand reputation and customer trust. Even highly respected brands like UnderArmour and British Airways experienced serious issues after their mobile apps were breached. Business leaders should consider the benefits of adding security automation directly into the development pipeline to drive quality and protect users in a cost-effective manner.

Faster, Lower Cost Developer Cycles

Suppose a business creates a 12-week plan to develop, test and release a mobile app software update with a labor budget of $60,000 per week. The development team creates a schedule to write the code in 10 weeks and allocates a two-week period for a manual security pentest. After developers finish writing the code, they must wait for the pentest results to point out any security issues. When testing uncovers security issues, devs, security analysts and QAs must determine which issues need to be remediated. Then the devs can fix the issue, retest to ensure it is properly fixed, then release it. Most of the time, finding any issues delays the release by weeks or months, delaying the expected revenue generation and other business benefits by weeks or months, in turn.

Instead, businesses can take a cost-effective approach by running security automation continuously through the development life cycle. Dev teams can write code, allow security automation to run during off hours, and have tickets with built-in remediation info sent back to devs the next day. This can remove weeks of testing and remediation delays to ensure teams release on time and on budget. Businesses can cut costs further by establishing common coding, testing and remediation policies in advance and then deploying an automated policy engine to focus on just those security requirements and issues relevant to the policy to operate at the fastest pace possible.

Integrating automated security testing into development tools enables DevSecOps teams to build, test, fix and release faster with security built in. Not only does this strategy increase the security and quality of the mobile app, it drastically lowers development costs by improving team efficiency.

Faster, Lower Cost Security Testing Cycles

Every organization with a mobile app has different security requirements. Those with low-risk mobile apps may outsource their security testing once or twice a year. Those in highly regulated industries like healthcare and financial services may have internal security analysts and test as often as every release and event outsource pen testing quarterly. Whether testing internally or externally, security testing costs can become a major pain point for companies looking to manage their finances efficiently.

The average cost of a full-scope, two-week outsourced manual pentest costs around $15,000 to $20,000 per test. If an organization tests its mobile app on a quarterly basis, its pentesting costs jump to $60,000 to $80,000 per year. Internal pentesting teams can potentially be cheaper, but organizations still need to pay for analysts’ salaries and the tools and resources they need to conduct tests. Whether a business has an internal security team or relies on outsourced manual pentests, leveraging security automation can significantly reduce costs.

Businesses with internal security teams can use automation to test builds immediately after devs release code. By continuously assessing code quality from start to finish, security teams can eliminate their testing time and speed up release cycles. Businesses that outsource security testing can use security automation to cut costs by reducing the frequency of full-scope manual pentests. Instead of testing on a biannual or quarterly basis, continuous automation can help reduce the testing frequency to once or twice a year with comparable coverage.

The most efficient approach possible is the hybrid security automation approach of guided testing that combines daily automated security testing as mobile apps are built with periodic human security analysts for coverage of the parts of the mobile app that automation can’t cover. Guided testing starts below $20,000 per mobile app for unlimited automated security testing integrated into DevSecOps toolchain with four periodic guided tests per year, slashing outsourced quarterly pentesting costs by more than 75%.

Mobile apps play an important role in helping businesses generate much-needed revenue, but running fast and cutting corners without security built in ultimately places the business and users at risk. So business leaders should take extra steps to keep them secure, and securing mobile apps can be achieved without breaking the bank. By incorporating security automation and innovations like guided testing into the mobile app development process, businesses can maximize the speed of delivery while simultaneously reducing costs and improving quality.

February 9, 2023
What Developers Really Think About Pentesting

A developer in their natural habitat is often spotted in a state of deep concentration, coding awesome features to tight deadlines. Feature-building is often our favorite part of the job, and really, it’s the fundamental outcome of the software development life cycle (SDLC).

However, as we have discussed before, many of us are still prioritizing features over security best practices. After all, in most organizations, it is set up to be someone else’s job and adequate security training for us is limited. Penetration testing and static analysis scanning tools (SAST) are just part of the overall process to mitigate security risks, operating rather independently from what we do — until the code bounces back to us for hotfixes, of course.

It’s at that moment that many developers think, “Do the pentesters hate me?”

These interactions often define a team and culture. The concerning thing is, the lack of communication, understanding and overall collaboration has created tension, at least on the side of the developer.

Think about it: Imagine you’ve spent a few hundred hours sculpting a marvelous statue, and then someone comes along with a hammer and starts smashing bits off it after they’ve told you its foundations are not up to scratch. That’s the perceived dynamic between a tester and developer — the latter has their software darlings slaughtered by an outsider that hasn’t labored through the process with them; instead, they’ve extended the workload and delayed the satisfaction of shipping code.

Having moved into the security space long ago, I can see both sides of the story. And no, pentesters don’t hate developers. The pentester is in all likelihood, overworked and under a lot of pressure. As such, a constant stream of common security bugs that could be quite easily fixed at the code level take up time, resources and headspace away from the really serious issues.

I always saw pentesters as kind of like parents. They want you to do well, and when you don’t they’re not mad, just disappointed.

Now that I’ve put that (perhaps slightly unfair) image in your mind, let’s explore this a little deeper. What has caused this world view among developers?

Resentment for Being Told What to Do

Nobody likes feeling as though they’ve done a bad job, or that someone doesn’t like their work. Sadly for developers, when static analysis and pentest results come back to them, it can feel like a report card. They’ve been given low grades, but at the end of the day, their bosses assess them on the features they’ve built and the time they’ve delivered them, not whether there were vulnerable elements in the software or not.

For the poor pentester, this is a case of “don’t shoot the messenger.” It’s nothing personal — they are tasked with finding bugs, and they found them. Granted, at a person-to-person level, maybe some pentesters are grumpier than others, but they’re not (or shouldn’t be) out to crucify development teams. It would be far easier for both teams if they were on the same page with what constitutes security best practice. Developers are not expected to be perfect; realistically, the testing team is there to protect them from shipping vulnerable code.

Minor Issues vs. Higher Priorities

It’s true, a developer’s highest priority will always be the building of features, and in this crazy world of rapid digitization, it will have to be done at speed. While some coders have a personal interest in security and secure coding, the general sentiment is that security is “someone else’s problem,” which inevitably includes pentesters.

Most common vulnerabilities are indeed minor issues to remediate — once known, the fixes are simple to execute for things like cross-site scripting (XSS) and SQL injection. The problem is, many developers don’t realize they’re introducing them in the first place, and these seemingly minor issues are the small window of opportunity an attacker needs to cause devastating problems for a company. According to Akamai, between November 2017 and March 2019, SQL injection vulnerabilities accounted for 65% of all web-based attack vectors. For a vulnerability that has had a known fix for more than 20 years, that is a sobering statistic.

Some pentest teams do assist in the remediation of security bugs, but others will provide a report of the bad news and expect developers to work through hotfixes, even if they have moved onto a different project by the time this happens. And in some cases, the development team may be faced with a report that includes bugs they can’t (or shouldn’t be expected to) fix. It still has to be part of the findings, and again, not taken personally.

The “happy medium” for this would be pentesters, security personnel and development managers acting in more of a mentor role to ensure the team has what they need in terms of effective training and tools, giving individual coders the best chance to succeed and code securely from the very beginning of the SDLC. Both teams really should be meeting half-way to ensure security is considered from the start, as part of a healthy DevSecOps practice.

Lack of Knowledge vs. False Positives

Static analysis is an element of the security process in the SDLC, and static analysis scanning tools (SAST) play a fundamental role. And yes, false positives are an issue with these and other types (DAST/IAST) of scanners. It’s an annoyance in what is already a slow process, requiring manual code review and putting pressure on both developers and pentesters alike. Pentesting personnel have taken time to meticulously set up custom rules to avoid inaccurate readings and provided company-specific guidance, yet some false readings slip through and end up in front of a head-scratching developer.

This process isn’t perfect, but the other problem is that many developers lack enough knowledge to mitigate a lot of common vulnerabilities on a consistent basis. With security training rare in tertiary education, and on-the-job training varying in its effectiveness, it stands to reason that there may be some overconfidence at play as well (and it’s not their fault, we as an industry need to get better at equipping them with what they need).

Remediation Tasks

Sometimes, there is an assumption by overworked engineers that pentesters are just hanging in the wings, waiting for the moment to strike by testing an application and raining on the development team’s parade. They are over-testing, they’re nitpicking, they’re creating extra work.

The only problem with that is they, too, are overworked (more so, in fact, the cybersecurity skills shortage is at dire levels and getting worse) and simply don’t have the time to test without reason. They are not the sole decision-makers in prioritizing testing; it could have been requested by senior leadership, a customer, as part of a security audit or even determined as a result of a bug bounty program.

For a developer, being pulled off current feature-building sprints to work on security fixes is annoying — especially if it’s not their work. Perhaps a previous team did the last update, or another vendor. However, security is everyone’s problem. That doesn’t mean every developer has to take ownership of security bugs as though they have made them all themselves, but they do need to come to the party in terms of security being a shared responsibility.

Where to from Here?

Sometimes, a mindset shift can be all it takes to make significant headway in solving a problem. We’ve talked about the rather frosty reaction a developer has to less than favorable pentest results, but what if they could turn it into a challenge? Perhaps they could think of the pentester as a friendly competitor; someone they can beat at their own game. After all, a security-aware developer that can eliminate common bugs as they write code is going to make their job much more difficult. By contrast, a developer with no focus on security is going to be comprehensively bested by their pentester counterparts when they can easily break their software.

Pentesters and developers may not be joined in harmony 100% of the time, but their relationship can be vastly improved when an organization addresses security as a key priority, and empowers teams with the right knowledge and tools to succeed — especially developers. It comes down to whether a company-wide, positive security culture is a priority, and if we are to fight the (currently) losing battle against common vulnerabilities, it absolutely should be.

June 17, 2020