staging-devopsy.kinsta.cloud

Tag: devsecops

  • One Year Out: What Biden’s EO Means for Software Devs

    One Year Out: What Biden’s EO Means for Software Devs

    It has been just over a year since president Biden issued executive order 14028 (EO) to improve the nation’s cybersecurity posture. Despite the Log4j vulnerability and a worldwide increase in ransomware attacks, this EO signaled a major step in improving software security at federal agencies and establishing cybersecurity as a priority for the U.S. government. While the agencies tasked under this EO have made significant gains, it is important for industry to understand just how much progress has been made since its inception and what that progress means to the average producer of software.

    To understand the effects of the EO, it is important to remember that president Biden does not have the authority to order any government agency to purchase specific software, nor does the president have the authority to require any governmental agency to procure specific software. Instead, the EO instructs heads of agencies to perform specific tasks that will ultimately define more stringent cybersecurity requirements to protect government offices. This doesn’t mean the EO solely applies to U.S. government contractors; if your company is anywhere in the software supply chain leading to a U.S. government purchase, then you need to pay attention to the EO and plan accordingly.

    One of the first of those tasks was for the National Institute of Standards and Technology (NIST) to solicit input from the public and private industry surrounding the structure and management of software supply chains. That work resulted in an NIST publication on EO Critical Software in July 2021. That publication helped outline security measures for software use, including applying practices of least privilege, network segmentation and proper configuration. It also helped NIST to frame the Secure Software Development Framework (NIST sp800-218v1.1) (SSDF) published in February, which provides a set of fundamental secure software development practices.

    This guidance, along with the definition of a software bill of materials (SBOM) by NTIA in November and the updated Cyber Security Guidance for Supply Chain Risk Management (NIST sp800-161r1) released in early May now form part of the risk-based framework that OMB instructed agencies to follow.

    What it Means To Be “EO Compliant”

    Before beginning any discussion about EO compliance, it’s important to recognize that until there are contract clauses defined—and those contract clauses are incorporated into contracts—there isn’t anything to comply with. That process is part of the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation (DFAR) effort, and the proposed clauses haven’t been published yet. Despite this, we do know enough to start preparing for future compliance and creating processes that will allow for EO compliance.

    The first step is to recognize whether your organization is a supplier within a supply chain of a U.S. government agency. In the context of the EO, that would mean any organization who creates, procures or embeds software into a component or assembly that is ultimately bought by a U.S. government agency. This includes open source software, low-code/no-code frameworks and DevSecOps tooling, to name just a few of the scenarios where U.S. government use might not be immediately apparent. 

    With that in mind, any provider of software within a supply chain should be prepared to answer questions about EO compliance if their software can be used in the U.S. government setting. For some, this could mean updating a few processes; for others, it may prompt a much larger set of changes in the development cycle. Those willing to change may be more likely to retain relationships or gain favor with government suppliers.

    How Software Providers Can Be Proactive

    There are three critical steps that can be performed today as part of preparing an organization for future EO compliance requirements. The first thing providers can do is generate a complete SBOM for their software in an NTIA compliance format and be prepared to attest to its accuracy. While it is not yet clear how the U.S. government will expect to receive an SBOM or what attestation format will be required, generating compliant SBOMs is one of the easiest tasks software producers will face as part of a post-EO world.

    Next, providers should baseline existing software development practices with the objective of aligning with the SSDF (NIST sp800-218v1.1). The SSDF defines a set of tasks that NIST views as a minimum requirement to securely create software and manage the software creation process. If the government procurement requirements include an attestation of compliance to the SSDF, then software producers who already know how well-aligned they are to the SSDF will be that much closer to compliance. 

    Lastly, providers must implement controls related to open source governance. While an SBOM helps identify open source use and the SSDF includes tasks related to its use, neither specifically defines how any software producer is expected to govern their use of open source software. Open source software is fundamentally different from commercial software in many ways; the most important differentiator is that it is freely downloadable from the internet. This free access means that creators likely do not know who their consumers are and thus cannot proactively provide updates or security information. Open source governance processes can help to fill that gap.

    Why It is Time to Embrace the EO

    These first steps can help software providers address the initial requirements that have come out of Biden’s EO and those who get a jump on implementation will have a leg up against their competition. Starting now can save providers a major headache in the long run, as federal agencies seek an understanding of how much risk they bear when operating the software you produce. 

    The rapidly changing cybersecurity landscape was a key driver behind Biden’s EO. Threat actors are evolving their tactics to keep pace with improving cybersecurity postures and it is in everyone’s best interest—from the federal government to the private sector—to put an emphasis on security. An important place to start—regardless of where you are in any software supply chain—is by taking the steps necessary to demonstrate that you understand the risks inherent in operating software and are actively working to reduce those risks for your customers.

  • Threat Modeling as a DevSecOps Practice

    Threat Modeling as a DevSecOps Practice

    Software engineers are always under pressure to build more software, faster.  At the same time, there is increasing regulatory and market pressure for secure software that meets users’ and regulators’ requirements for data privacy.  This dynamic often puts software engineers at odds with application security or product security teams.

    In fact, 81% of developer teams at large enterprises have launched applications that feature insecure code, according to one researcher, with half doing this on a regular basis. The firm argued that developers and security architects need a better relationship, and I couldn’t agree more.

    These technical teams are working towards the same goal, so it’s in everyone’s interests—particularly senior leadership—to create a more cohesive working environment by breaking down barriers between teams. If the security of a system is designed and enforced by an external security team—disconnected from the rest of the engineering team—then this only reinforces security as a separate silo. But companies can ease tensions by embedding the responsibility for security in the engineering teams themselves: This is the thinking behind DevSecOps. Thinking about security starts when engineers think about solving the problem: At design time.

    While the shift left movement was born two decades ago with the goal of ensuring product testing happened early in the development stage, I believe we need to start left to make real change. In adopting this culture, security and privacy will be less of a bolt-on afterthought and a built-in fixture within the development process, ensuring that engineers and security teams alike are aligned and have visibility of each other’s objectives. 

    By reimagining the build, test, fix, build, test, fix cycle through building an architecturally secure design in real-time, technical teams can detect software vulnerabilities sooner rather than later, which means more efficient product deployment. This is where the process of threat modeling as a business tool can be of great benefit.

    Historically, threat modeling was a static, slow and manual process conducted on whiteboards, as part of a workshop led by a third-party security expert who lacked institutional knowledge of the inner workings of the company. However, this has evolved dramatically into an easily implemented, automated security practice that can be baked into the development and security cycle from the outset, empowering organizations to start left.

    Through automated threat modeling, the security workload burden is relieved for both security architects and engineers. Companies are, in turn, better positioned to keep pace with the cadence of ongoing software rollouts, as an automated platform suggests security improvements as an application evolves. The launch phase bottleneck that’s typically created during the testing stage is therefore removed, as security requirements are identified prior to development—which means that risk is managed before a line of code is even written. Based on this, it should quickly become apparent what a time- and cost-saving exercise threat modeling is.

    No developer or security specialist wants a flawed product to hit the market, so it makes good business sense to adopt a new approach that will lead to better outcomes. Enterprises that introduce threat modeling as part of their development and cybersecurity processes will be on course to embed a true DevSecOps system within the company, transforming the relationship between these two departments.

    In my experience, culture and growth are the key factors for enterprises that decide to adjust their cybersecurity diet to include automated threat modeling. Convincing the app dev teams to invest time into the process is, by far, the most significant cultural hurdle to overcome, because they need to witness the benefits—and up until this point they’re disconnected from the AppSec process.

    Once equipped with the tools and knowledge, delivering secure design will be second nature to developers and a new collaborative culture will be created. In essence, the more teams are given oversight of and accountability for software design flaws, the easier it is to recognize how vital these preliminary checks are.

    Likewise, there comes a stage of business growth when the ‘security first’ and ‘start left’ mindsets are essential to keep enterprise project management on track—and this ties into the culture. As the rate of scale within a company begins to increase and the pace of software deployment must quicken in line with customer demand and market competitiveness, discovering flaws at the end of the design process just isn’t an option. 

    With developers and security teams responsible for vast amounts of code, product resilience on delivery is crucial and ensuring a robust DevSecOps culture is the route to success.

  • Survey Surfaces Raft of Application Security Issues

    Survey Surfaces Raft of Application Security Issues

    A global survey from ReversingLabs found 87% of respondents agreed that software tampering has become a more frequently-used cybersecurity attack, but only 37% said they have any means to detect it.

    The survey, which polled 300 IT and security professionals, was conducted by Dimensional Research on behalf of ReversingLabs, a provider of a platform for analyzing any file, binary or object. Despite software tampering’s frequency, only 7% of survey respondents said they could detect software tampering at each phase of the software development life cycle.

    Just as troubling, only slightly more than half (51%) reported being able to protect their software supply chain with only a third being able to actually check for tampering once an application is final and deployed, the survey found.

    Overall, more than half of respondents (54%) said their organization knowingly released software with potential security risks. Nearly every respondent (98%) also acknowledged that reliance on third-party software use, including open source software, increases security risks.

    On the plus side, more than three-quarters of respondents (77%) said they appreciated the value of a software bill of materials (SBOM) that makes it possible to ascertain what software artifacts are being employed within an application. However, only 27% of respondents said their organization currently generates and reviews SBOMs. A full 90% said they are finding it increasingly difficult to create and review SBOMs. Nearly half of the survey respondents reported that SBOM processes today involved manual steps.

    Other SBOM hurdles respondents cited included lack of expertise (44%) and inadequate staffing to review and analyze SBOMs (44%).

    ReversingLabs CEO Mario Vuksan said that while it’s still early days as far as SBOM capabilities are concerned, a series of high-profile zero-day vulnerabilities has forced the issue into the spotlight. Organizations are now spending months looking for every possible instance of newly discovered vulnerabilities because no one is quite sure what application components are running across an extended enterprise, he noted.

    However, as DevSecOps best practices continue to evolve and mature, it’s also clear that SBOMs will play a critical role in securing software supply chains, Vuksan added. The challenge is that in the age of microservices, application environments are now much more dynamic as components are ripped and replaced with greater frequency, he added.

    SBOMs, of course, are just one element of what will be required to secure a software supply chain. Many organizations are now reviewing their software development processes and uncovering uncomfortable truths about how software is currently built and deployed. The ultimate goal is not to slow down the rate at which software is developed but to make sure there are guardrails in place that prevent insecure software from being deployed in the first place. Far too many developers today still view cybersecurity reviews as tasks to be avoided in the name of meeting an application deployment deadline.

    Hopefully, that won’t continue to be the case as more responsibility and accountability for applications security shifts left toward developers and DevOps teams. In the meantime, however, when it comes to application security, it’s apparent there’s still much room for improvement.

  • Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit Emerges to Address Cybersecurity Policy-as-Code Orchestration

    Jit today emerged from stealth with a free namesake orchestration platform beta that automatically implements security plans as code.

    Aviram Shmueli, chief product officer for Jit, said the company will both make security plans it developed available as code within GitHub. In addition, Jit will make available a service through which customers can submit documents and spreadsheets that Jit will convert into a custom security plan that can be executed as code.

    Fresh from raising $38.5 million in seed funding, Jit is aiming to advance the adoption of DevSecOps best practices by enabling cybersecurity policies to be more easily implemented as code via its orchestration platform, said Shmueli. The Jit platform enables developers and DevOps teams to take advantage of a graphical tool to automatically implement security policies within a DevOps workflow with a single click, he noted.

    The goal is to eliminate the need for separate DevOps teams to create security policies that each would need to individually manage, added Shmueli.

    In theory, DevSecOps best practices require shifting left the responsibility for security toward application development teams. The challenge is that development teams generally don’t have the expertise required to craft effective cybersecurity policies. Jit is making a case for a platform that makes it simpler to automatically implement vetted cybersecurity policies.

    Exactly how far responsibility for application security will shift left remains to be seen. Developers generally prefer to spend as much time as possible creating business logic rather than implementing cybersecurity policies. As such, it’s frequently left to a DevOps team to find a way to consistently implement cybersecurity policies across multiple applications. Each DevOps team will need to decide how much they can rely on the policies defined by Jit versus opting to implement a set of policies defined by their internal cybersecurity teams. The issue that often arises is cybersecurity teams lack programming skills; the only means available to define cybersecurity policies is some type of document or spreadsheet that, one way or another, needs to be converted into code.

    Given the ongoing chronic shortage of cybersecurity expertise, it’s apparent that more efficient methods for sharing cybersecurity best practices are required at a time when application environments continue to both rapidly expand and increase in overall complexity.

    Regardless of the DevSecOps approach, the pressure to address application security is mounting in the wake of a series of high-profile cybersecurity breaches. Organizations of all sizes are now reviewing software supply chains that are increasingly being targeted by cybercriminals. Security policy-as-code tools make it possible to ensure that applications don’t, for example, communicate with an external system without express permission.

    One way or another, the level of application security currently being attained will improve in the months ahead as more mandates are enforced. The only real issue remaining is the amount of disruption to existing processes that will be required to achieve that goal.

  • Why is Security Still in the Way? A Look at DevSecOps Right Now

    Why is Security Still in the Way? A Look at DevSecOps Right Now

    According to industry trend reports for 2022, DevSecOps is now considered to be one of the most effective approaches to building software quickly and securely. This effort, of course, means development, security and operations teams commit to addressing security as early as possible in the software development life cycle (SDLC). The goal of the shift into DevSecOps revolves around the need for more automation, streamlined CI/CD pipelines, less friction among teams and plenty of time for productive innovation. Incorporating DevSecOps practices into an organization unites security, compliance and development issues into a collaborative concern, one that allows DevOps to move fast without jeopardizing code quality. 

    As we approach the middle of 2022, it’s worth looking back and considering why security is still standing in the way of smooth software development. Security vulnerabilities have always been present in the process, and yet these pesky bugs continue to be the biggest threat to software performance. The question is, why?

    The Truth About Security

    Software has always been deployed and shipped with some existing bugs. But as software and services continue to dominate our everyday lives, the reality of this statement continues to plague both businesses and the end user. On some level, software development has yet to evolve into the next phase of security. Code is still rolled out regularly, only to discover security vulnerabilities in production. Some say the way software is developed today actually lends itself to defects, mostly because the pace of work required supersedes best practices around AppSec. 

    While the larger cybersecurity industry—and every DevSecOps team in the world—is striving to make software more secure, many organizations still prioritize speed and productivity over digital risk. This means the state of security (and, to some extent, the DevSecOps world) has become somewhat lopsided, with some enterprises making great efforts while others embrace a more lackadaisical approach. To make matters worse, many professionals today believe there has been a general under-investment in cybersecurity over the past several decades. 

    The Next Phase of DevSecOps

    The shift to remote and hybrid work models has led to mass adoption of cloud technologies and digital transformation, across all sectors and industries. As a result of this evolution, organizations today need to bear in mind that the more services they use, the more digital threats and overall risk they face. As this exposure to vulnerabilities increases, so does the need for new approaches to security. 

    The majority of modern enterprises do, in fact, have a security process in place, as well as other risk management solutions. But with the cybersecurity reckoning of 2021 and the stakes of cloud computing being higher than ever, businesses right now are feeling the pressure to think long and hard about why security still isn’t a guarantee. The trend of slowing down software development to address security more thoroughly, also known as the secret sauce of DevSecOps, is not free from roadblocks—but it is also far from optional. For many organizations, the implementation of DevSecOps practices feels less like security and more like speed bumps that just slow down the shipping of software. 

    Even so, the effort to improve security is happening now. Organizations do not need several solution platforms or tools to get started. They can begin right away; evolving their security tools and practices as they grow the business. With this growth comes one of security’s biggest challenges—scalability. Because toolchains across the cloud have become more and more complicated, setting policies and/or workflows in one tool is challenging. While these issues can be largely addressed by the adoption of an end-to-end security solution, organizations must continue to focus on strengthening supply chains, improving security oversight, and bolstering their approach to DevSecOps. Some ways to make this happen include:

    • Making sure CI/CD pipelines are integrated with DAST and SAST testing in development
    • Ensuring developers and DevOps teams complete vulnerability scanning before commit or merge, as they write code
    • Minimize manual security as much as possible with automated AI/ML tools to support more effective scanning and monitoring
    • Invest in management solutions that improve security in a multi-cloud environment

    Addressing the Supply Chain

    According to an industry survey, 60% of companies have decided securing the software supply chain should be a top priority for 2022. When we think about software supply chain attacks, we need to think about better controls to validate its integrity through all stages of the SDLC. Obviously, DevOps and automation have provided considerable help in this area; however, they cannot pull all the weight of security without proper governance and guardrails. 

    With a secure supply chain comes better security, as well as compliance, privacy and transparency. When a supply chain is secure, it can automatically enforce policy requirements for things like instrumentation, testing and architecture. As a result, software development and deployment become a repeatable process that is also reliable. Teams across the organization can rest assured that the products and services they are building comply with security expectations, such as validating code before production with static analysis and scanning tools. 

  • When DevOps-as-a-Service (DaaS) Meets Security

    When DevOps-as-a-Service (DaaS) Meets Security

    One of the most recent IT methodologies to be offered as a service is DevOps, a cultural and practical approach that brings development and operations teams together under one umbrella of work. DevOps-as-a-Service (DaaS) ensures that everything related to the selection, management and maintenance of DevOps tools and infrastructure, including all policies and procedures, are addressed through a centralized team who are able to provide this service to development teams across the organization. 

    From a 30,000-foot view, DaaS represents DevOps capabilities made accessible to practitioners through portals and APIs. Because DevOps capabilities vary among organizations, there is no standardization of these services. For the business, DaaS enhances competition. Application users and developers find DaaS improves overall software development, while specialized DaaS teams say it improves the management of DevOps capabilities.

    What Are the Other Benefits of DaaS?

    DaaS offers many benefits, especially to development teams who no longer want to spend all their time configuring and deploying the necessary security tools to run DevOps pipelines. This means it’s no longer necessary to understand all the differences between DevOps tools and the underlying infrastructure, as the appropriate tools and technologies are automatically deployed for development teams. As a result, developers are able to focus their efforts on creating innovative software at the speed of business. 

    Further, Daas delivers clear business and operational benefits in the form of a more streamlined process for facilitating DevOps across the enterprise. Daas supports governance while also enabling centralized oversight and visibility into development workloads and productivity. As we know, this shift leads to increased accountability among teams and an overall optimization of business processes. Add on resource efficiency and cost savings through tool selection, and it’s easy to see why DaaS has found a home in the world of software development. 

    But despite the benefits, Daas also presents new security challenges that can’t be fully addressed by traditional management solutions. These approaches are often sluggish, expensive, and/or incredibly complex to manage.

    What About Security and DevSecOps?

    Because the principles of DevSecOps proactively address the risks and threats associated with DevOps processes, it has seen rapid adoption in recent years. By integrating AppSec tools and strategies within a DevOps pipeline, developers are able to find and fix security vulnerabilities earlier within the software life cycle—not after the fact. This ability is what allows developers to generate secure and high quality software from the beginning, while also preventing any deployment delays stemming from last-minute security checks in production. With DevSecOps processes in place, AppSec testing becomes seamless and transparent for developers, who need a frictionless experience to facilitate steady and reliable software development and deployment. 

    DevSecOps is a  natural fit for the as-a-service delivery model. Similar to DevOps, AppSec involves various tools, policies and processes that demand a certain degree of professional expertise—not to mention the time and resources it takes to to select, maintain, and deploy them to drive DevSecOps practices. Security and development teams looking to  implement and manage DevSecOps can reap major benefits from a centrally defined and managed process, to be administered by a specialist team and delivered “as a service” to those in charge of DaaS.

    Standardizing AppSec through a DevSecOps-as-a-Service offering would guarantee security is applied evenly across all DevOps activity, thereby allowing businesses to produce secure and high-quality software consistently while also supporting AppSec compliance demands. This shift also establishes a foundation where a holistic and homogenous view of AppSec can be found, one that is critical to the assessment and management of application and business risk. 

    Developing DaaS Metrics

    First, don’t try to boil the ocean by measuring all applications at the same time. Instead, choose an application that’s supported by DaaS processes and appoint a specialized team to develop metrics for the application. This team can look many ways—but would likely include stakeholders, developers and other DaaS-supporting roles. Service-level indicators (SLIs) and service-level objectives (SLOs) are also baked into this model, which are chosen to best suit the requirements of an individual application. 

    Once the most valued SLOs of DaaS are determined, the service can be tailored to identify the most critical SLIs. With this knowledge, things like instrumentation, telemetry and analysis requirements can be identified and used to design alerts, dashboards, analyzers and more. Next, setting up policies and procedures around accountability establishes a complete solution. And once the solution for the chosen application is tested, confidence kicks in and creates an easier process for adapting and expanding the process around other applications. 

    This means DaaS can provide many key capabilities to both the organization and the teams who rely on them. A specialized DaaS team can then figure out the best metrics for larger implementation on any application. As a result, SLOs can be evolved for other future applications, to be used as a baseline for future improvements. 

     

  • Orca Security Adds CLI to Improve Cloud Security

    Orca Security Adds CLI to Improve Cloud Security

    Orca Security has extended its cloud security platform via a command-line interface (CLI) that makes it simpler to integrate with a wide range of DevOps tools.

    Rather than relying on agents, the Orca Security platform creates a risk profile using read-only access to block storage accessed via a runtime hosted on Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform. That approach, dubbed SideScanning, eliminates the need for DevOps teams to deploy and maintain agent software to ensure cloud security.

    The platform then scans both workloads and cloud configuration metadata to build a map of risks that better enables DevOps teams to prioritize cloud security efforts.

    Orca Security CEO Avi Shua said the CLI will now make it easier to shift responsibility for cloud security further left toward developers and the DevOps teams that support them by making it easier to scan for vulnerabilities with the context of a larger set of DevSecOps best practices.

    Cloud security remains a major challenge because infrastructure is often provisioned by developers that have little to no security expertise. It’s almost inevitable that mistakes will be made. Orca Security is making a case for a tool that enables organizations to identify those security issues without deploying additional agent software across a wide area network.

    The challenge, of course, is determining how far left to shift responsibility for application security. Even when alerted to a security issue, many developers may not fully appreciate the severity of that issue, noted Shua. Many developers also assume their cloud service provider is providing a level of security that they actually don’t. It’s the responsibility of the entity deploying the application to secure it and the associated configurations used to deploy it. Integrating a cloud security tool within a DevOps workflow becomes critical because it enables more members of a DevOps team to evaluate potential risk to the business as the application is being built rather than after it’s running in a production environment, he added.

    Many existing DevSecOps tools don’t provide enough context; all they do is provide static analysis of the code that’s been deployed, Shua noted. Developers need to have a deeper understanding of which issues represent a level of risk that requires their immediate attention, he said.

    There is, of course, more focus than ever on cloud security as more organizations review how their software supply chains are constructed in the wake of a series of high-profile cybersecurity breaches. Many are discovering that the level of security visibility they have into cloud computing environments is limited, at best.

    It’s not likely security concerns will slow down the rate at which applications are now being deployed in the cloud. Instead, the challenge is better understanding how to secure those applications using substantially different tools and processes than those used to secure applications within an on-premises IT environment.

  • The APIs You Really Don’t Know About

    The APIs You Really Don’t Know About

    A few years ago, we were rightly warned about the amount of exposure our APIs created. A massive attack surface that often used “security by obscurity” as its primary method of protection. We’ve come a long way since then, building secrets, tokens, RBAC and even more into our API interfaces.

    We’re still behind in getting comprehensive lists of APIs, but this bit is getting better as time moves on. Increasingly, both API management and DevSecOps markets are helping to catalog new APIs, and both the API management and application and API protection markets are helping to protect APIs that are unknown by tracking calls moving through the network. By using proxies, it is relatively easy to capture calls to APIs and report the list of APIs (and sometimes much more; about parameters and data transport, for example) to security or operations staff.

    In summary. the API management and security market has been doing great work, searching out the various APIs that are active in our systems, and cataloging new APIs as they are created. This gives us a comfortable and complete look at our current API environment and how it is protected. Most of these tools help protect what isn’t currently well protected.

    If only that really were all of the APIs in our networks. Unfortunately, that’s not the case. Because the ones not in this “complete list” can be the most insidious. As always, it is what you don’t know that poses the biggest risk.

    You see, there are APIs that are not currently maintained and are not currently actively accessed. Say you have an application that you installed from a third party—open source or purchased, either one—and then stopped accessing. Well, it is still sitting out there. The APIs are available—not necessarily documented and not necessarily secured. For security staff, this is how nightmares begin.

    Historically, we could count on these interfaces to be private. Those days are long gone in the hybrid environment. They might be private, but the definition of “private” is much looser than it has historically been and if there is a route from the internet to the API, it’s not private, and for well-known applications, is a time-bomb.

    This is another reason to clear out old versions and/or redundant installations of things like web servers and databases. Don’t make excuses—just upgrade them to the most recent version or remove them entirely. You can do this by merging what they do with a newer/better-protected installation or by just stopping them and fixing the apps that this impacts. “Turn it off and see what breaks” is admittedly a risky step, but sometimes will prove necessary to lock down the environment. If you don’t know what is using it, I’d argue your security risks are larger than an unprotected API hanging about, but that’s a topic for another blog.

    Meanwhile, keep rocking it. There is so much in your purview that we have to discuss what you don’t know about in the domain you are the specialist in. That’s not a weakness in you, that’s a statement about how much crap is tossed on your plate while making the org more competitive. And you’re dealing with it. So smile, keep kicking and lock down the scary bits.

     

  • Why DevSecOps Should Be Top Priority

    Why DevSecOps Should Be Top Priority

    DevOps culture and process are integral to maintaining the pace of cloud-native software development for organizations, especially when code deployments might take place many times a day. The ability to instantly create, populate and scale cloud applications and infrastructure, often automated through code, allows enormous agility and incredible speed. But moving this quickly means security is often left in the dust.

    The reality is many organizations still haven’t come to grips with how to properly secure the cloud. A lack of cloud security experience, coupled with legacy security policies that don’t encompass the cloud and a shortage of cybersecurity expertise relevant to cloud environments, presents a challenge. And cybercriminals are moving quickly to exploit these gaps: a 2021 report showed that almost half of the more than 2,500 disclosed cloud-related vulnerabilities recorded were disclosed in the last 18 months. 

    Due to the agile nature of cloud technologies, security must be integrated at every stage of the DevOps life cycle—also known as DevSecOps. A DevSecOps mindset is an absolute necessity for any organization that is leveraging the cloud, and requires new security guidelines, policies, practices and tools.

    The Cloud is Vulnerable

    Data breaches are among the most urgent concerns of any organization today. A 2021 report revealed that data breach costs rose from $3.86 million USD in 2020 to $4.24 million USD in 2021. The techniques that adversaries used to infiltrate the cloud differ from on-premises environments. Malware attacks are far less prevalent; instead, attackers exploit misconfigurations and other vulnerabilities.

    Another major concern is that organizations are usually using multi-cloud, which can cause a visibility issue. It can result in cloud workloads and traffic that are not properly monitored, leaving security gaps to be exploited by attackers. Also, DevOps teams tend to provide employees with far more privileges and permissions than needed to perform their job, which increases identity-based threats. According to research, nearly 80% of cyberattacks leveraged identity-based attacks to compromise legitimate credentials. 

    Threat actors will also deploy a variety of attack methods to compromise an organization’s cloud environment. Lateral movement is a common technique that involves threat actors going from the point of entry to the rest of the network (for example, infiltrating an end user or system hosted on-premises and then shifting their access to the cloud). Research showed that adversaries move quickly—in just 98 minutes they can move laterally from a compromised instance to another instance within the victim environment. 

    Alternatively, another way for attackers to profit from cloud vulnerabilities is by installing cryptominers onto a company’s system. Cryptocurrency mining is an activity that requires large amounts of computing power. Threat actors will use compromised cloud accounts to carry out this process and extract as much profit as possible, while simultaneously using up the company’s resources. 

    Shifting Security Left

    Protecting the cloud means securing an increasingly large attack surface that ranges from cloud workloads to virtual servers and other technologies that underpin the cloud environment. Attackers are always looking for soft spots they can exploit, particularly vulnerable cloud applications. With organizations moving to the cloud now more than ever to meet the needs of a remote workforce, opportunities to exploit cloud apps have increased. 

    Traditionally, code is subjected to security as the last phase before release. When vulnerabilities are exposed, either the release is delayed or the development team has to scramble to correct each security issue while the security team has to scramble to check the revisions. For DevOps teams, shifting security left ensures vulnerable code is identified as it is developed rather than in the testing phase, which reduces costs and results in secure cloud apps.

    The concept of shift left security is an essential part of the software development life cycle, and getting it right must be a top priority. By embedding security into the earliest phases of the development process, organizations can achieve DevSecOps and significantly reduce the security concerns around cloud-native software and application development. 

    Effective Cloud Security can Enable DevSecOps 

    Organizations that use DevSecOps tools and practices can build a powerful and secure cloud foundation. Unifying the visibility of multi-cloud environments and continuous intelligent monitoring of all cloud resources are essential in cloud security. That unified visibility must be able to detect misconfigurations, vulnerabilities and security threats while providing actionable insights and automated remediation for developers and DevOps teams. 

    Additionally, it’s essential to have the right security policies in place that enforce cloud security standards to meet (or exceed) industry and government regulations across the entire infrastructure. This includes everything from multi-factor authentication to general security best practices for all employees and robust incident response that ensures the company is prepared for an attack.

    However, the core of any effective cloud security strategy should always be up-to-date threat intelligence. Adversaries are constantly finding new ways to target the cloud and search for any weaknesses they can exploit. Having the latest data about threat actors and their tactics, and then applying it to breach detection is an absolute must. Threat intelligence enables security teams to anticipate threats and prioritize defense, mitigation and remediation effectively to preempt them. Delivering all this functionality from the cloud and for the cloud through DevSecOps provides organizations with the prevention, detection, visibility and response capabilities they need to beat attackers.

  • Competing Priorities Prevent Devs From Creating Secure Code

    Competing Priorities Prevent Devs From Creating Secure Code

    The recently released Secure Code Warrior State of Developer-Driven Security Survey revealed that developers continue to wrestle with secure coding practices in a working environment that has long prioritized features and functionality and speed at the expense of security. 

    Of the more than 1,200 developers who took part in the survey, only 14% named security as their top priority. Security was seen as a bottleneck—an astonishing 67% of these developers said they routinely left known vulnerabilities and exploits in their code and 48% shipped products with known vulnerabilities.

    These statistics raise eyebrows, sure, but they are also unsurprising. In the survey, application security fell behind creating quality code, application performance and the ability to solve real-world problems on the list of developers’ priorities.

    In many cases, these results showed that security is either ignored in favor of meeting demanding timelines, developers would rather improve an application’s performance or they simply lack the required training to fix security problems. Regardless of the reason, it is a continuing problem.

    The Need to Balance Security in Development

    As the survey showed, developers often worked with secure code in silos. Security controls were limited to a single category instead of a holistic view of fundamentals. In many cases, developers relied on existing or pre-approved code rather than writing new code free from vulnerabilities. This assumed that the code inserted meets proper security needs, but that assumption often fell short.

    That said, developers who write code often find themselves inadvertently introducing vulnerabilities. This is not entirely the fault of those developers, but some of the blame lies with the cultural risk acceptance of the organization.

    The software organizations themselves must put more onus on secure development. As we saw from the SolarWinds attack, deficiencies in code can lead to massive disruptions. While not all application vulnerabilities have the reach of SolarWinds, businesses often allow for too much risk to pass in their code; that gets passed on to customers and developers are made the scapegoats.

    Provide Developers With the Right Skills

    Security leaders must first ensure developers have the requisite skills to code securely and to make improvements. That includes not just writing the code but also how code is committed through the entire development process. Developers often need hands-on training in proper coding patterns created in the languages and frameworks they commonly use.

    Organizations can no longer overlook security and ship potentially exploitable software. Security must be added earlier in the development process and be seen as imperative to success. The survey showed that many developers believe secure coding is out of their realm of expertise. A staggering 86% said they found it challenging to practice secure coding, while 92% of developer managers said their teams needed more training in security frameworks.

    This highlighted that developers do not get the right kind of training—nor are they get enough exposure to security best practices. It also underscores that designing for security is not seen as an essential skill for developers to have.

    Reasons for Optimism

    While our survey highlighted a disturbing trend, it also offered reasons for hope. The survey showed that attitudes have changed, and 66% of developers expected security to become a more significant priority over the next 12 to 18 months. Hiring managers echoed this sentiment—82% expressed an interest in hiring developers who are knowledgeable in security over those who are not.

    Businesses today have put themselves and their customers in a risky situation; organizational leaders must be agents of change to mitigate this risk. They need to apply a security-first mindset and empower their developers to better integrate security into the development process. Timelines must be revised to allow this to happen. If it continues, the current state of application security will only lead to more (and more severe) breaches. Now is the time to ensure DevOps teams and developers have better access to security training and more time to put those practices into action to ensure long term success.