devopsy.kinsta.cloud

Category: DevSecOps

IBM Unveils Simulation Tool for Attacking SCM Platforms

At the Black Hat USA 2022 conference, IBM today revealed it is making available a toolkit for launching simulated attacks against source code management (SCM) platforms. The toolkit was launched as a proof-of-concept.

Brett Hawkins, head of adversary simulation for the X-Force Red arm of IBM Security, said the SCMKit takes advantage of the REST application programming interface (API) functionality in most SCM platforms to launch various types of attack modules using validated SCM platform credentials. IBM also described a series of attack scenarios that the simulation tool can be used to launch.

The SCMKit can currently launch simulated attacks against GitHub Enterprise, GitLab Enterprise and Bitbucket Server. The kit can support reconnaissance, privilege escalation and persistence attack module capabilities for creating personal access tokens or secure socket shell (SSH) keys. The SCMKit is based on a modular framework that makes it possible to add additional modules in the future, added Hawkins.

IBM created the SCMKit to focus more attention on an attack vector that can be exploited to compromise a software supply chain, said Hawkins. In the wake of a series of high-profile security breaches, the Biden administration issued an executive order that required federal agencies to review the security of their software supply chains. While there is more awareness of the issue than ever, Hawkins noted there has not been nearly as much focus on identifying specific attack vectors against SCM platforms that cybercriminals are able to exploit.

It’s not clear to what degree organizations are launching penetration tests against their preferred SCM platform as they work to secure software supply chains. However, it won’t be long before testing the security integrity of those platforms becomes more commonplace. In some instances, organizations will launch those tests themselves. In other cases, third-party IT services firms will be tasked with launching those tests.

Of course, the challenge is that penetration testing techniques are also often used by cybercriminals to conduct reconnaissance. The SCMKit doesn’t uncover any new techniques, but it does provide cybercriminals with a guide for launching attacks against SCM platforms. As such, IT organizations should assume these types of attacks will increase in frequency in the months ahead.

Regardless of the tool employed, it’s clear that cybercriminals have come to appreciate the fact that software supply chains are the soft underbelly of IT. Organizations today have typically focused most of their security efforts on production environments. However, malware inserted into, say, a software repository could easily find its way into multiple downstream applications. At some future date, the malware then reaches out to a command-and-control system that then enables cybercriminals to, for example, launch a ransomware attack or simply exfiltrate data. That malware could also move laterally across an application environment to wreak additional havoc.

It may be a while before the full extent of the threat to application security is fully appreciated, but as more organizations embrace DevSecOps best practices to secure their software supply chain, it’s all but certain that penetration testing will become much more pervasive in DevOps environments.

August 9, 2022
The Everything-As-Code Revolution and the OWASP Top 10

After years of stagnation, the Open Web Application Security Project (OWASP) Top 10 list finally saw some shakeup.

Most notably, insecure design debuted on the list as the number four security risk to web applications.

“If we genuinely want to ‘move left’ as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures,” OWASP says.

That hits the nail on the head. It’s a great sign for the industry that organizations are adapting and continuing to shift left responsibly, and points toward the everything-as-code future we’ve been imagining.

This addition by OWASP finally recognizes a key reason why organizations struggle to move the needle on addressing security issues. A lot of security today is reactive and organizations find issues long after they deploy applications, leaving security teams to act as firefighters at a time when there are too few security professionals in just about every industry.

To effectively move forward, we need a shift in thinking.

Studies have shown that if organizations addressed these same issues in design, they would eliminate the costs of firefighting and significantly improve developer productivity. It would also free security teams to focus on the strategic needs of security.

This change from OWASP recognizes that security needs to have a seat at the table when key software design decisions are made and it requires empowering security teams in the same way the DevOps teams have been empowered to own and manage the application’s security design and implementation.

A Unique Inflection Point: DevSecOps

Security breaches continue to pile up, yet many organizations haven’t reexamined their reactive approach, which ignores the architectural problems causing the issues. We can’t continue to operate this way.

We need a more dynamic and comprehensive approach to security in cloud-native applications. We need to acknowledge the failure of detecting misconfigurations too late in the development life cycle. It’s impossible to scale that way, and you end up creating too many rules in the process.

We need more proactive engagement, which can be difficult in an application development world where velocity is king.

Developers and DevOps teams should view security as trusted partners and engage them early in the development life cycle. They should understand that they have a shared responsibility for security. Security teams should embrace automation that fits into the developers’ workflow and makes their lives easier by democratizing security.

The Everything-as-Code Future

If we can continue to shift left responsibly, we’ll keep moving the industry forward in a way that will have ripple effects, including in the OWASP top 10.

In a perfect world, we would see frameworks and application infrastructure address the input validation issues that make up a large part of the top 10 today. Those issues should be off the list and the top 10 should focus on the systemic issues—like insecure design—that lead to the current list.

As we move toward an everything-as-code world where the boundaries between the application and the infrastructure blur, OWASP may focus more broadly on everything-as-code, which would include a new class of issues such as cloud code, infrastructure-as-code, pipeline-as-code and security-as-code. While there’s certainly more work to do, that would be a strong signal that we’re moving in the right direction.

August 4, 2022
JFrog Aligns With AWS to Improve Cloud Application Security

At the AWS re:Inforce event this week, JFrog announced it integrated its JFrog Xray software composition analysis tool with AWS Security Hub, a cloud security posture management (CSPM) service that alerts IT teams whenever a security issue is detected.

In addition, JFrog also announced it is participating in a preview of an AWS Marketplace Vendor Insights tool. AWS created Marketplace Vendor Insights to provide cybersecurity and compliance risk assessments of the third-party software made available on the AWS marketplace.

Steve Bohac, partner marketing manager for JFrog, said the integration of JFrog Xray with AWS Security Hub will streamline the flow of cybersecurity alerts an IT team receives by centralizing the delivery via AWS Security Hub. AWS this week similarly moved to integrate the Amazon GuardDuty Malware Protection service with AWS Security Hub.

Collectively, security services accessed via AWS Security Hub are intended to make it simpler for IT teams that have deployed application workloads on the AWS cloud to embrace DevSecOps best practices. JFrog Xray, for example, is designed to be deployed using the AWS Lambda serverless computing framework, noted Bohac.

The arrival of these services comes at a time when the focus on cloud security, as part of a larger effort to better secure software supply chains, is rising in the wake of a series of high-profile application breaches. In general, cloud platforms are more secure than on-premises IT environments; however, the processes used to build and deploy cloud applications are often problematic in that mistakes are frequently made. Developers routinely use open source tools like Terraform to provision cloud infrastructure and accelerate application development. Most of those developers have limited cybersecurity expertise so, inevitably, there are misconfigurations that cybercriminals have become more adept at finding and exploiting.

The ongoing chronic shortage of cybersecurity professionals means most organizations are not able to keep pace with the rate at which workloads are being deployed in the cloud.

Fortunately, more organizations are also starting to embrace DevSecOps best practices to make software supply chains more secure. The challenge is that no matter how much time and effort is made to educate developers, there will always be a development team that makes a mistake. Tools such as JFrog Xray make it feasible to discover those issues before an application is deployed.

It’s not clear how long it might be before DevSecOps has a meaningful impact on cloud application security. The number of applications already deployed on cloud platforms is already innumerable. In theory, at least, as each of those applications is reviewed and updated, they should become more secure as DevSecOps best practices are more widely employed. However, it may be years before the overall security of cloud applications materially improves.

Eventually, the next generation of cloud applications should be substantially more secure than their predecessors. The hope is, in the meantime, any vulnerable cloud applications that have security flaws won’t be exploited before IT teams can bring to bear the resources required to fix them. In effect, it is a race against time.

July 29, 2022
Lock Down Your Toolchain

We have done amazing things with Agile and DevOps, increasing IT responsiveness to levels that most people would not have believed and our business counterparts only dreamed of even a decade ago. Think about it—we can check in a single source file and kick off a chain of events that involves half a dozen or a dozen software tools that collectively shepherd an entire application through the development process to deployment. Through all of that, only deployment might require human interaction, depending upon corporate policy. In many places, even deployment does not require a person. Just development.

We didn’t get to this point by moving slowly, and sadly, we did not get to this point by acting in a security-first manner. Thanks to the security-toxic mentality that DevOps was born in, we have had to go back and try to bolt on security where it was ignored initially. But we’ve largely managed that process. We have tools that handle privileges, monitor connections, scan source, look for vulnerabilities in support software, even scan entire container definitions before the build.

Know what most of you still don’t have? A truly secure toolchain. This is bad policy. A knowledgeable attacker is going to go after one of the aggregate locations. Places like container management servers that give them access to a lot of resources. Or the toolchain, which gives them access to every bit of software the organization develops. If an attacker wants to do code injection without detection, the toolchain in charge of builds and deploys is it.

And yet, for ease of use and keeping up with iterations, many of you have credentials for the toolchain stored in easily accessible places so that whichever tool is running the show has access to credentials for each piece of the toolchain. I wish I could say “No one keeps that data in flat files anymore,” But alas, I cannot.

One of the reasons it is not sufficiently secured is that build toolchains fall somewhere between Dev security and Ops security. That means our teams that came from a development background are not focused on security for the build chain, and our teams/team members that came from an ops background are not focused on the toolchain selected and often initially deployed by developers.

Which brings me to my recommendation. Put security professionals on the toolchain to verify it is locked down at every step. There are a lot of places for the toolchain to be insecure, not just poorly stored credentials. And the toolchain touches all of IT’s crown jewels. So make sure it isn’t wide open. If your organization doesn’t have dedicated security staff, bring in consultants to review the toolchain and make recommendations. There are some great security teams for hire out there that will be happy to lend a hand.

And keep rocking it. Your teams are building and deploying at a rate never seen before—even if DevOps is “slow” at your org, it is still likely faster than its predecessors—for doing anything. So keep working miracles, and lock down your castle’s the inner keep.

July 27, 2022
Future of DevOps: Trends to Watch

Technology is transforming every aspect of industry, and digitalization and automation have flourished in the past few years. DevOps has established itself as an indispensable software development methodology for successful digital transformation.

According to a recent market survey, the DevOps market will exceed $20 billion by 2026, growing at a CAGR of 24.7% from 2019 to 2026. DevOps has facilitated rapid and dependable software development, delivery, improved quality and higher customer satisfaction.

DevOps, too, is continuously evolving to meet the changing demands of the corporate environment. Let’s look at the future of DevOps and the trends you should expect to see.

Serverless Computing

DevOps teams will see a rise in the adoption of serverless architecture, mainly because of the massive capital and operational costs of server infrastructure. Numerous DevOps groups are working with modular components offering an overview of the pipeline. Moving these modular components to serverless architecture will empower groups to mitigate a few pieces of errands identified with pipeline architecture and focus on deployment and development of the product.

Serverless computing streamlines overall DevOps operations, including the complete software life cycle, from development to deployment, testing and maintenance in one place. Also, serverless computing reduces the developer’s workload by taking care of server maintenance, such as cloud monitoring and system updates. Other prime USPs include flexibility, reliability, speed and cost-efficiency.

Microservices Architecture

Microservices architecture has been gaining popularity as an alternative to traditional monolithic architecture in the IT industry, and this trend is expected to continue. Microservices architecture is a pattern of organizing computer systems into segments that can scale on demand. A microservices architecture pattern is the next evolution of service-oriented architecture (SOA) that structures an application as a collection of coupled services. If one piece of the application fails, microservices make it easy to identify and contain the issue without disrupting the whole application.

DevOps and microservices architecture enable decentralized teams to innovate rapidly, maintain control over their tech stack and standards, track performance metrics, supervise the development and release cycles and reduce overall consumption time by achieving shorter software release intervals.

Low-Code/No-Code Applications and Platforms

To keep up with the demand for new applications and features, many organizations have turned to low-code/no-code development to deploy applications swiftly. Adopting a low-code approach with DevOps is a game-changer. It enables developers to experience higher agility and gives the organization a competitive advantage in the fast-paced, demanding software market.

Low-code applications allow non-technical ‘citizen developers’ to contribute to software development with the help of visual interface integration. In addition to end users, developers and DevOps engineers are set to play a crucial role in this trend, using low-code platforms and tools that offer drag-and-drop elements and other extensions. These low-code application development tools support every aspect of software development, including app ideation, analysis, software design, code development, quality assurance, deployment and documentation.

DevSecOps

Many large enterprises are integrating and automating security into DevOps processes. The transformation from DevOps to DevSecOps is expected to gain even more momentum in the future. According to a forecast, the DevOps market size is expected to reach $5.9 billion by 2023 at a CAGR of 31.2% during the forecast period.

More companies will embed security controls earlier in the software development cycle to ensure application security. Tools and frameworks will simply integrate with CI/CD pipelines and testing tools will see a rise in 2022. DevSecOps empowers developers to consistently track, monitor and remediate security defects during the various stages of development while improving the speed of delivery and quality.

Kubernetes and GitOps

Kubernetes is an open source container orchestration platform emerging as an infrastructure trend on the operations side. Kubernetes will expand further into the software development space in 2022 and beyond. It will ease the task of starting a local Kubernetes cluster on a developer’s machine. Kubernetes security is expected to take center stage as well, through infrastructure-as-code (IaC) scanning.

GitOps is a Kubernetes-related infrastructure trend that allows developers and IT operators to use Git to manage clusters and deliver efficient, secure applications without misconfigurations. It automates releasing incremental updates, and consistent delivery will enable developers to build, test and deploy software rapidly.

AI and ML

Artificial intelligence and machine learning have already transformed the way businesses operate nowadays. In 2022, it is anticipated that AI/ML will further streamline and accelerate every phase of the SDLC. It enables DevOps teams to enhance their performance through intelligent automation, improving feedback and managing alerts.

Advanced analytical methods like predictive analytics are becoming increasingly important as the market evolves. AI can enable proactive investigation of the DevOps pipeline to identify problems and offer possible solutions. AI and ML integration also enable deep learning, data mining, statistics and modeling, becoming an integral part of your business’ workflow.

Conclusion

DevOps continues to evolve and pivot to drive significant IT transformations that directly bolster business goals and objectives. It will assist in enhancing the company’s ability to design, produce, launch and maintain high-quality software solutions. The above trends will help organizations move rapidly beyond automation, focusing on continuously improving outcomes. These trends are catalysts for creating a regular and dependable release pipeline and building better communication between development, IT and business teams.

July 22, 2022
How DevOps Teams Can Defend Against API Attacks

Remember when ransomware was the main security threat that DevOps teams needed to worry about?

Those days are over. Ransomware attacks are certainly still happening, but API security breaches—which increased by a whopping 600% in 2021—are now poised to become the top attack vector for threat actors, according to Gartner.

That’s the bad news. The good news is that, in many respects, the security practices that DevOps teams already have in place to defend against ransomware can be repurposed to deliver API security, too—with a few tweaks.

Keep reading for a look at the state of API security today, along with tips on expanding upon DevOps’ existing ransomware defense techniques to protect your APIs.

The Preponderance of APIs

Although it may seem surprising that APIs have suddenly become an attacker’s best friend, it’s actually not when you step back and think about how deeply dependent we’ve become on APIs over the past half-decade.

APIs have been around for a long time. But until relatively recently, APIs were used mostly for specific types of applications, B2B or infrastructure integrations. It wasn’t until the pivot toward microservices and distributed architectures that internal (or east-west) APIs became the glue that holds application environments together and carries information (which is sometimes sensitive) between the components and micro-components of an application.

As for external APIs, publishing public APIs has become a basic expectation for virtually any business with a software product—to the extent that there are now something like 22,000 public APIs out there as well as several orders of magnitude more internal APIs.

The result is a world where APIs create potential attack vectors against virtually every application or service. It only makes sense, then, that the bad guys are increasingly focusing on exploiting APIs as a means of obtaining access to things you don’t want them to have.

From Ransomware Protection to API Protection

You might think that securing APIs requires fundamentally new security tools and practices. In reality, though, there are extensive parallels between mitigating ransomware risks and mitigating API security risks. And DevOps teams are a major line of defense against these.

Here’s how to extend an anti-ransomware strategy to an anti-API-exploit strategy.

Prevent Lateral Movement

Like ransomware, which propagates from endpoint to endpoint laterally by exploiting flaws and vulnerabilities, API exploits also typically spread laterally across an environment.

This means that even if you can’t prevent all API (or ransomware) attacks from breaching your perimeter, you can take steps to make it hard for breaches to expand. By detecting malicious activity inside your environment early on, you can stop lateral propagation of the threat before it leads to a largescale compromise.

Focus on Data Security

Ransomware attacks and API attacks are both focused on compromising the same crown jewel: Your data. Ransomware attackers want to hold that data for ransom. API attackers—such as those who stole sensitive information from compromised Peloton accounts, or others who breached LinkedIn’s API to scrape data about 700 million users—typically want to exfiltrate it, possibly to resell it or maybe just to harm your business’s reputation.

Mitigating both ransomware risks and API security risks, therefore, boils down to securing your data. By enforcing strong access controls and segmentation over what both internal and public APIs can do, you mitigate the risk of data exfiltration due to API security breaches.

Use Behavioral Security Models

Investing all of your signature-based security controls in attack prevention doesn’t work well for either ransomware or API attacks, especially when they are zero-day or unknown attacks. While you certainly should do what you can to harden your environment, it’s impossible to guarantee that a breach won’t slip past your defenses.

That’s why deploying behavior-based security models is key to protecting against both ransomware and API attacks. Behavioral security models detect anomalous activity inside an environment, such as unusual types of requests or strange request patterns. By modeling and baselining behaviors and detecting anomalies based on your model, you can prevent attacks from spreading once they are underway.

Don’t Rely on Perimeter-Based Defenses

Along similar lines, trying to protect the perimeter of your environment is not a surefire defense against either ransomware or API attacks. Instead, you need to distribute protections across all of your endpoints, applications, services and so on.

Again, nothing will guarantee that attackers won’t get in. The success of your defense hinges, in large part, on your ability to make it hard for them to escalate their attack from a small-scale breach into one that impacts a wide array of resources.

Look Beyond the Surface

Ransomware and API attacks are similar in that both often involve attack methodologies designed to elude common security monitoring tools.

For example, attackers might try to leverage ports 80 or 443 (the default HTTP/HTTPS ports), which will almost always be open on firewalls. It’s therefore imperative to avoid relying just on standard ports or on encryption to protect API traffic. Instead, you must look deep into the payload, then parse and understand the protocols. It is also important to monitor and collect data from multiple sources, then correlate and analyze them to a get a deeper understanding of what is actually going on within the environment.

Conclusion

To be sure, ransomware attacks and API security attacks are fundamentally different in some respects. They involve the exploitation of different protocols and the goals of attackers are usually a bit different.

But in terms of how attackers operate, what they want to steal (your data) and the limitations of perimeter-based defenses, ransomware attacks and API attacks are actually pretty similar.

That’s why developers and DevOps teams don’t need to rethink their entire security strategy to cope with the surge in API attacks. Instead, do what you’re already doing to protect against ransomware and use those techniques to help secure your APIs, too.

July 20, 2022
Poor App Remediation Creates a Vicious Vulnerability Cycle

A survey of 200 security professionals found nearly 83% of respondents reported that an increase in the rate at which applications are being deployed has led to an increase in the reintroduction of previously remediated vulnerabilities.

The survey, conducted by Waratek, a provider of tools for managing security-as-code, found 93% of the security professionals polled currently work for organizations that have embraced DevOps or Agile development methodologies. Half of the respondents (50%) described maintaining security in those environments as challenging, with a slightly higher percentage (58%) noting that implementing security within DevOps process does slow down the rate at which applications are deployed. A full 85% also noted that manual security work slows the rate at which applications can be deployed as well.

Surprisingly, more than two-thirds (67%) of security professionals also said they would be willing to sacrifice security to allow applications to be delivered on time.

Nearly three-quarters (71%) also said they expected that keeping pace with DevOps teams would only become more difficult, with 61% also noting that keeping pace with DevOps teams resulted in delays to other critical security projects.

Waratek CEO Doug Ennis said the root cause of the application security challenge can be traced back to continued reliance on manual processes. It’s too easy for developers, for example, to reuse code that contains vulnerabilities that were fixed in one version of an artifact but not another, he noted.

That lack of automation also conspires to increase overall cybersecurity fatigue, added Ennis. More than 50% of survey respondents reported they spend days or weeks each year investigating false positives. There simply are not enough cybersecurity professionals available to make sure applications are secure without relying more on automation, said Ennis.

In the wake of a series of high-profile security breaches, there is more focus on software supply chain security than ever. However, it’s not clear to what degree organizations are embracing automation and DevSecOps best practices to secure those software supply chains. The challenge is finding a way to build more secure applications without slowing down the rate at which those applications are built and deployed.

Many organizations are clearly already shifting more responsibility for application security left toward developers and DevOps teams with hopes of achieving that goal. However, it’s still the cybersecurity team that get the call whenever there is a breach, noted Ennis. There must be workflows in place that enable automatic remediation in ways that don’t always require organizations to wait on a developer to build and deploy a manually-applied patch that is usually inconsistent, he added.

The Log4Shell vulnerability is a perfect example of how flawed the current process for building and deploying patches is, Ennis explained.

In fact, as more applications are deployed, developers often find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building and deploying secure applications that leverages automation is clearly required. The challenge is creating automation that consistently achieves that goal each and every time required in a way that doesn’t break any of the applications that need to be fixed.

July 19, 2022
What SASE Means for DevOps Teams
You have probably heard the acronym secure access service edge (SASE), and it’s hard to ignore its impact on the technology industry. SASE is a cool new way to implement networking in hybrid environments, and the most important thing about it is that it bakes security into the network fabric. In plain English—when you plug in, you are secure by default.

SASE will have a special impact on two fields near and dear to the hearts of DevOps teams:
1. Cloud security—SASE has the potential to transform how we practice security in the multi-cloud, and unify it with security in the central data center.
2. DevSecOps adoption—SASE can make DevSecOps easier to adopt and might become essential infrastructure for globally distributed DevSecOps teams.
Let’s understand the anatomy of the SASE beast, and understand how it will affect DevOps in the years to come.

What Is SASE?

SASE is a cloud service that extends networking and security capabilities to support hybrid organizations’ dynamic, secure access needs.

SASE combines WAN capabilities with network and security functions, such as firewall-as-a-service (FWaaS), zero-trust network access (ZTNA), secure web gateway (SWG) and more.

A SASE platform bundles multiple security capabilities, including SD-WAN and services like SWG, CASB, ZTNA, FaaS and SaaS. This multi-region, multitenant architecture supports a distributed and remote workforce. SASE uses inspection engines located at points of presence (PoPs) near the endpoints rather than in the data center. SASE clients send traffic to the nearest PoP.

The core characteristics of a SASE architecture are:
- Global SD-WAN—A private SD-WAN backbone helps reduce latency by avoiding the public internet.
- Distributed architecture—SASE inspects traffic and enforces policies at the edge using multiple inspection engines.
- Cloud infrastructure—SASE delivers services via the cloud, so tenants don’t have to maintain hardware and other infrastructure resources. This approach is scalable and cost-effective.
- Identity-based access—Access controls use identity markers like the user’s location and device.
SASE Adoption Drivers: Why Do Organizations Want It?

Cost Reduction

Using physical and virtual appliances from multiple vendors is highly cumbersome and costly. SASE enables organizations to replace this disparate model with a single, cloud-native solution. Organizations can use SASE to deliver more technologies and services via one provider instead of several. As a result, it eliminates the cost of miscellaneous network appliances and optimizes cloud costs, by reducing the resources and bandwidth needed to operate a cloud environment.

Edge-to-Edge Security

SD-WAN is an integral component of SASE, providing features such as an active-active failover and WAN optimization that improve performance and increase network resilience. SASE solutions are based on the concept of security automation, with a fully managed network security stack that typically includes SWGs, next-generation firewalls (NGFW), next-generation network architecture and intrusion prevention systems (IPS). This model helps protect all edges, achieving better network visibility.

Data Protection

SASE provides a holistic data protection experience that automates multiple DLP processes, including data discovery and data classification of storage locations, data usage and data in transit. It employs various security measures, such as user and device authentication, to enable control over access to data and resources at all times. Additionally, SASE DLP seamlessly rolls out protection policies across the entire network.

Impact: How SASE Will Transform the Cloud Security Stack

The emergence of services like PaaS, SaaS and IaaS has encouraged organizations to allow remote work. The cloud supports distributed workforces and streamlines business processes, but it also exposes companies to network-based threats. Many organizations store sensitive data with third parties accessed online.

The cloud security stack can easily become siloed, with team members unsure of their responsibilities and overlooking critical processes. A siloed stack is more labor-intensive and harder to track because the security team uses multiple security systems. It can also create alert fatigue, making it hard to identify threats.

While employees mostly work in the cloud, security efforts often focus on the data center. SASE shifts the focus to the cloud while ensuring seamless integration between security services.

With SASE, a single provider delivers the entire security stack, ensuring it functions as a unit. For instance, an SWG uses threat intelligence data to block suspicious traffic, sending unidentified files to a sandbox for testing. The security team can manage the entire stack from one intuitive interface.

Most activities occur at the edge—SASE secures the edge using an identity-driven approach. It is also cloud-native, ensuring a seamless experience.

Impact: How SASE Will Promote DevSecOps Adoption

SASE provides the following advantages for adopting DevSecOps.

Facilitating Collaboration

SASE helps reduce the challenges involved in cross-team collaboration. Essentially, SASE combines network security with WAN optimization. Modern DevOps teams are physically separate but must work together, requiring reliable and secure connections between team members.

The DevOps approach emphasizes time-to-market, so DevOps teams look for ways to accelerate the CI/CD cycle and push releases faster. An important part of the process is reducing the DevOps team’s reliance on the network and security teams. SASE solutions help optimize performance and enhance security, so the DevOps team doesn’t have to wait for the infrastructure team to configure resources. SASE gives DevOps teams the necessary control and operational cadence without compromising security or performance.

Enhanced Networking

SASE can improve the overall network performance by providing integrated failover and load balancing capabilities. DevOps teams must have reliable connectivity and cannot tolerate disruptions when deploying new software or fixing bugs. Fast, reliable application performance is key to the DevOps workflow.

The SASE architecture improves the networking, ensuring the organization’s edge devices, cloud resources, data center and remote users remain connected. The DevOps team doesn’t have to handle the infrastructure because it is self-healing, fully optimized, and secure. The solution automatically switches to another path if a line fails or a path becomes congested.

Security By Default

SASE protects DevOps projects with built-in security features. When implemented properly, it integrates many security technologies into the network stack. The DevOps team doesn’t have to worry about attackers intercepting sensitive information. Every security service shares the same, unified context to increase visibility and fill gaps that are often present in traditional security architectures. SASE mitigates the vulnerabilities exploited by attackers using NGFW, SWG, IPS, MDR and antivirus services in a single architecture.

SASE can secure internal applications and their interactions, reducing the burden on the DevSecOps team. Applications running on a SASE-based SD-WAN benefit from the added protection of zero-trust network access (ZTNA) and software-defined perimeter (SDP). These technologies help ensure that all interactions between applications and endpoints are secure.

Proprietary apps are often too sensitive to expose to the public Internet. SASE secures these applications by obfuscating traffic, securing all entry points with NGFW, and restricting access with zero-trust network architecture. It constantly inspects all internal application traffic for cybersecurity threats.

Conclusion

In this article, I explained the basics of SASE, which packages multiple networking and security solutions into one managed service.

SASE is giving organizations a new level of flexibility and agility with regard to their core infrastructure and is introducing the concept of security-by-design. Instead of fighting hard to “secure all the things,” we are moving nearer to a world where the “grid” our organization operates on is secure by default. This won’t make DevSecOps any less important. But it will allow us to build our applications and services within a secure, controlled hybrid environment.
July 19, 2022
To Prevent Supply Chain Attacks, Build Secure Code

More than a year after the massive SolarWinds cyberattack, targeted companies continue to feel its ramifications in both reputation and financial cost. Moreover, the global software supply chain remains vulnerable to severe attacks, whether from a hostile nation-state like Russia–now increasingly in the cybersecurity spotlight due to fears of retaliation due to U.S. sanctions–or from any other cybercriminal party.

As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, which could allow the persistent presence of malicious actors on a seemingly infinite number of networks; nor do we know when the next attack will happen with potentially more dire consequences. For example, six months after the discovery of the Log4j vulnerability and its associated patches, we know that networks and products all over the world remain unpatched, vulnerable and exploitable in all sorts of companies both big and small.

This must change. And that change must start from the inside out; meaning programmers, developers and DevOps teams should start building code more securely in the first place. That also means that those who use cloud services, third-party black box software or the services of hub companies, whose networks connect both suppliers and customers, should better understand how code development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce the number of attacks.

There are signs that the industry is moving in this much-needed direction—or that there are at least more discussions about it. The White House recently hosted meetings with technology experts focused on this very topic. And this spring, the SEC announced that it may begin requiring some companies to report cyberattacks within four days and also provide details about their cybersecurity posture. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices for coding protocols. But regardless of eventual, still-hypothetical regulation, developers—and cybersecurity professionals at hub companies—should give serious thought to the process they use to securely build their products.

Beyond Open Source Code

Of course, an oft-recommended solution is to move to open source software (OSS). Although open source code is still vulnerable to attacks, the processes and practices involved in creating OSS code are transparent, which goes a long way toward crippling the ability of bad actors to conceal themselves. But such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.

However, there are other steps that could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making gray and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could find and access. Ideally, developers could then also remedy or repair these vulnerabilities. Also, assessing security at every step of the development process could give crucial insights into vulnerabilities before they are discovered in the wild by malicious actors.

Code-Signing and Scanning Innovations

Implementing other methods to spot security flaws in code, including in open source code, would also help. Using innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure life cycle and implementing security protocols for merging and accessing the product code; this could prevent cyberattacks from occurring as a result of a faulty (or nonexistent) SDLC process—the same way an electrical engineer couldn’t design a building electric plan without formal training and certification and participating in regular continuing education and recertification.

CISOs Need to Be Proactive

CISOs and IT professionals also have an active role to play. They need to evaluate the security of their products’ underlying code , taking full advantage of the software bill of materials (SBOM), which lists all components of software (and that could soon be required by law) but that is only one side of it. This needs to be coupled with measures like code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities in libraries and frameworks. And it is increasingly important to make sure that contracts with software service providers specify they are adhering to secure development practices.

With the world on high alert and the private sector especially vulnerable to state-sponsored cyberattacks, there has never been a better time to focus on building more secure code. This does not mean that all of the other aspects of cybersecurity—including threat intelligence, incident response plans and hiring and retaining talented professionals—will be any less important. But if the code underlying the software can itself become more secure, these attacks could become fewer in number and their damage less far-reaching.

July 18, 2022
Security Compass Makes Visualizing AppSec Threats Simpler

Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.

The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.

Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.

That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.

Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.

In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.

For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.

The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.

One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.

July 14, 2022