devopsy.kinsta.cloud

Category: DevSecOps

  • WhiteHat Security Allies With Bit Discovery on Vulnerability Intelligence

    WhiteHat Security Allies With Bit Discovery on Vulnerability Intelligence

    WhiteHat Security, a subsidiary of NTT, has announced an integration with Bit Discovery to make it easier for developers and cybersecurity teams to discover the extent to which the attack surface they need to defend might be impacted by a vulnerability.

    Bit Discovery maintains a database made up of more than 5 billion internet-connected assets and hundreds of third-party resources to automatically generate an inventory of the assets that make up an organization’s attack surface. Bit Discovery continuously scans internet-connected assets to monitor new domains, phishing sites and connected devices to provide cybersecurity teams with a deeper understanding of the threats their organization faces.

    WhiteHat Security integrated its application security platform for scanning for application vulnerabilities with the Bit Discovery database via application programming interfaces (APIs) to make it possible to search that database via a dashboard. All vulnerabilities surfaced via that dashboard are verified by WhiteHat’s Threat Research Center, a team of application security experts, to reduce any potential alerts that might actually be false positives.

    Craig Hinkley, WhiteHat Security CEO, said the goal is to make it simpler for organizations to shift more responsibility for applications security left toward developers in a way that doesn’t result in them chasing their tail every time a new vulnerability is discovered. Instead, a virtuous cycle of workflows can be created that enables developers and cybersecurity teams to collaborate more effectively, Hinkley added.

    Ultimately, the goal is to make scanning for application vulnerabilities a more natural extension of any quality assurance process. The simple fact that there is so much focus today on DevSecOps best practices only highlights how much work there is to be done before security becomes just another routine gate within an automated DevOps workflow, noted Hinkley.

    In the meantime, unfortunately, cybersecurity teams are finding it increasingly difficult to keep pace with the rate at which applications are being developed and updated. The Bit Discovery database integration provides a way for cybersecurity teams to have more relevant conversations with developers about which vulnerabilities need to be prioritized based on the actual threat they represent to the organization. In the absence of that integration, security becomes a losing battle, simply because developers and cybersecurity teams both are overwhelmed by the volume of vulnerabilities that would otherwise need to be investigated on their own without any assistance.

    The integration between WhiteHat Security and Bit Discovery comes at a time when the focus on software supply chains has increased significantly in the wake of a series of recent high-profile breaches. More attention is now being paid to preventing malware from finding its way into the application development process. The challenge is finding a way to provide developers with actionable insights into risks that need to be mitigated before and after an application is deployed in a production environment. After all, vulnerabilities are just as often discovered after an application is deployed as they are before.

    It may be a while before most organizations are able to implement a robust set of DevSecOps best practices, but the more reliable the vulnerability intelligence being provided to developers, the more likely it becomes they will act on it before a cybercriminal exploits it.

  • Private and Virtual Private LTE/5G Challenges Network Visibility

    Private and Virtual Private LTE/5G Challenges Network Visibility

    Digital transformation continues to disrupt the entire IT stack by shifting nearly every paradigm, including the new blurring lines between network infrastructure. New mobile network technologies are at the cusp of adaption in the enterprise networks with a growing number of innovations poised to enable expanded and more flexible connectivity with a gradual displacement of traditional Wi-Fi networks.

    The evolution began as new unlicensed radio frequencies become a part of the 3GPP 5G Release 16 mode of operation. This new mobile mode of operation has the ability to offer the necessary technology for mobile network operators (MNOs) to operate the unlicensed spectrum into 5G networks and make some of it available for corporate networking. New standardization will enable the enterprise networks to gradually adopt these new mobile networks to their connectivity framework, in order to leverage the benefits of new modern applications and alignment to their connectivity, scale and quality of service requirements.

    With the benefits of a new mode of connectivity – in a converged fixed or pure mobile infrastructure – there are always measurable risks that require attention. Specifically, the new mode of connectivity brings potentially new security threats and operational challenges that need to be addressed.

    New Operating Modes

    It is likely that incorporating this mobile technology will require starting from new operational modes; these will be imperative to grasp the direction and the adaption of private mobile networks in reality. Industry hype is certainly driving the trend towards the mode in which the corporate IT teams will be capable to deploy and operate the new private mobile network. However, at this point in time, the more realistic option will be that full control of design, deployment and operation will be from the MNOs, as they have strong experience, knowledge and risk mitigation capabilities. This mode of operation is also incentivized through the business aspects of creating a new revenue stream for the MNOs. This higher-margin business can provide more stringent security operations, particularly in light of better understanding the vector of attacks. Such an approach provides carrier-grade operations with the commitment of a service level agreement and correlation to the required corporate business agility and continuity needed by the enterprise.

    Questions like the who, what and where of network traffic need to be answered to prevent security threats and maintain network performance and reliability—in essence, identifying and maintaining the identity of the mobile subscriber in a complex hybrid model of mobile connectivity. A corporate mobile network can be completely private, well isolated from other networks with no roaming into the public network. It can also feature a less stringent traffic policy using a virtual slice of the private network with a segmented perimeter in which certain traffic will roam into a public network and will be tracked with respect to subscriber-aware policy. This latter option is a greater challenge because of the inherent separation of data or user and control planes in mobile network architecture is virtual rather than physical. Additionally, new mobile 5G architecture includes virtualization and network slicing to offer valuable versatility and scale, but it also makes NetOps and SecOps monitoring and control even more challenging. In light of the complexities, we can assume that the favorable and practical mode of new corporate mobile networks will be outsourced to an MNO that will operate in tight synergies with corporate IT teams. Their work will be based on a defined playbook to drive a gradual evolution of architectural reference models and pragmatic learning curve for corporate “do it yourself” operations mode. Complexities multiply in cases related to IoT and manufacturing applications in which the mobile core is required to be closer or co-located with the edge to support low latency and high throughput requirements.

    5G features a separation of data/user and control planes that is an architectural advantage, particularly helpful for large IoT deployments, dynamic scalability and services and higher data rates with greater bandwidth efficiencies. It offers more distributed processing for greater scale and less susceptibility to a single point of failure. It also represents a shift from best-effort networks to ones that can provide better, more differentiated levels of services and prioritization. This separation requires a new approach for network visibility to understand who is doing what. This is an issue for security as well as networking performance.

    The Challenge of Virtualized Network Functions

    Another challenge is that 5G virtualizes in software the higher-level network functions that traditionally have been performed by physical hardware. This virtualized network slicing means a sharing of physical resources that expand the attack surface by offering the potential for a sophisticated attacker to traverse from one virtual instance to another knowing that it will be difficult for security teams to detect this lateral movement. In addition, 5G radio network deployments may include significant expansions of small cells connecting in a campus geographically distributed environment, machine-to-machine communications and dynamic connections to multiple cells. All of these present a new frontier for attackers and new challenges for IT operation teams. Organizations need visibility and understanding of these new infrastructure resources to ensure a clear design and implementation to prevent security breaches and disruption of business continuity.

    The potential for significant expansion of IoT devices on corporate networks using 5G offers important advances for measuring and monitoring devices or making everything connected. At the same time, these lean devices generally have far less endpoint controls—particularly robust access control—than traditional computing devices, and it is difficult to add such controls directly to each unit. The rise of more IoT machine-to-machine communication and away from a hub-and-spoke model adds additional complexity. A proliferation of such devices also intensifies the need for deeper visibility and more automated security to scale with these deployments without the bottleneck of human intervention for each. This adds risks to the internal IT learning curve, making it an unlikely option and again, favors outsourcing to MNO experienced teams to design, deploy and maintain the corporate private mobile networks.

  • Empowering BizDevOps Teams With SLOs

    Empowering BizDevOps Teams With SLOs

    When BizDevOps teams are drowning in logs and false alerts and are spending more time on manual processes than on building and deploying new applications and features, the work suffers, morale suffers and the organization as a whole suffers. Releasing better and more secure software, faster and with real business impacts starts with a robust BizDevOps practice. A crucial step IT leaders can take to align the developer, operations and business teams is to create a shared language of service-level objectives (SLOs).

    SLOs are metrics for validating that software is meeting its technical and business objectives. Defining and implementing SLOs help align developer, operations and business teams, not only ensuring everyone is moving toward the same goals, but also providing a way to reliably measure how BizDevOps teams are progressing toward these goals.

    Here are three of the most impactful ways SLOs can empower your BizDevOps teams.

    1. Establish a Common Language Across the Delivery Cycle

    The best SLO gives you precise and actionable insight into your system. Take performance and resiliency engineering, for example. By defining SLOs for performance and error rates, teams can use common measurements to track progress toward meeting their quality criteria to ensure they are staying within their error budget.

    In this way, teams can use SLOs as a common language across the delivery cycle – something everyone from developers to operations to business teams can rally around, ensuring everyone is working toward the same outcomes. This aligns teams into a coordinated BizDevOps practice, where all sides have better insight into how each piece of the business feeds into the others. If an incident occurs, operations can use an AI-based observability platform to observe its trends and impacts across different product or service releases and automatically feed that information back to the developers, who can modify their builds accordingly. When everyone is using the same SLOs to speak the same language, BizDevOps teams can coordinate and communicate more easily and effectively.

    2. Creating a Culture of DevOps Resiliency by Shifting SLOs Left

    BizDevOps isn’t just a technical practice defined by tools and platforms. It’s also a culture change and a shift in mindset. SLOs can play a major part in this change. Shifting SLOs left into the delivery pipeline means giving developers feedback about the outcome of their work and real-time visibility into their business KPIs using consistent SLO measurements – ideally, on every code commit. This consistency gives them answers at their fingertips to make data-backed decisions that consistently deliver better business outcomes. Using SLOs for developer feedback is a fundamental building block of DevOps, but it’s also key to creating a culture and mindset of resiliency within BizDevOps.

    A resilient BizDevOps culture is more than just making changes to your technology stack; it’s about changing the mindsets of individual engineers and developers. Resiliency means strength and reliability; the trust that when something goes down, it’ll go right back up. It’s about building the processes and systems that guarantee flexibility for anything from managing crisis events to delivering service continuity. Shifting SLOs left helps facilitate this culture change by giving developers greater exposure to the impact their work has when it’s in production and when it’s deployed. It makes everyone feel they’re in the same boat, and recognizes developers, operations and the business teams as one cohesive unit.

    3. Integrating SLOs Into Remediation

    BizDevOps teams can use SLOs to enhance remediation and incident response efforts. With everyone working with the same metrics, BizDevOps knows with certainty when something is broken, can identify root causes more quickly and can develop agreed-upon incident responses to accelerate time to resolution. BizDevOps teams can then feed this incident response knowledge back into quality gates earlier in the development cycle to avoid future problems. This develops SLOs that have been “battle tested” and can be easily automated to make quality gate testing better on the development side, and incident response better and faster for the operations side.

    SLOs bridge the gaps between BizDevOps

    SLOs already serve a useful role in production, but they also can influence the ability to create a robust, resilient BizDevOps practice. Shifting SLOs closer to developers and using them as a shared language across the delivery cycle provides space for greater experimentation, more innovation and a culture of resiliency. SLOs can also be defined along business-relevant metrics, such as conversion rates, user experience or feature adoption. As a result, SLOs empower BizDevOps teams to respond more quickly to issues and deliver better digital experiences and business outcomes.

    SLOs aren’t just performance metrics – they’re a powerful tool for bridging the divides between the developer, operations, and business teams. SLOs can help cultivate a BizDevOps culture that delivers innovative, secure software faster and with tangible business value.

  • SecDevOps is the Solution to Cybersecurity

    SecDevOps is the Solution to Cybersecurity

    Anybody paying attention to world news will notice that the threats and risks perpetrated by cybercriminal actors, in many forms, is a serious problem on the rise, affecting individuals, organizations and nations daily. The cybersecurity threat space is indeed alarming and growing rapidly. The cybersecurity solution space is struggling to keep up. After all, there is no such thing as 100% security.

    What is the Solution to Cybersecurity’s Problem?

    In my opinion, the industry has long underestimated the problem of cybersecurity, which has resulted in solutions that do not sufficiently stand up to the cybersecurity threat space. What is clear is that solutions must come from rapid software changes that detect and plug security holes as fast as they are found, and continuously deploy innovative defensive solutions that keep bad actors off their guard. To do that requires Agile and DevOps continuous delivery practices coupled with a security-aware mindset.

    What is a Security Aware Mindset?

    To put things in perspective, it is useful to consider the mindsets of design, QA, operations and security.

    Design mindset – create a product or service that customers want, now. The Agile framework addresses this requirement.

    QA mindset – verify a product or service works the way customers expect it to, when it is released, for all production configurations available at the time of the release. The DevOps framework addresses this requirement.

    Ops mindset – ensure a product or service continues to work the way customers expect, for all production configurations, for the life of the product or service. The site reliability engineering (SRE) and ITIL frameworks address this requirement.

    Security mindset – defend valuables for organizations that create or use a product or service against unintended and malicious actions, by people and organizations, both inside and outside of the organizations, for all production and non-production configurations, for as long as there is something of value to protect. The DevSecOps framework was created to address this requirement; as we have seen, this does not yet offer sufficient safeguards for the growing cybersecurity threat problems.

    The security mindset has multiple additional vectors of thought required compared to the design, QA and ops mindset. This helps us to understand why the cybersecurity problem space is bigger and requires more comprehensive solutions.

    Not long ago I considered security assurance to be a subset of testing practices. In 2016, in my blog, “Seven Pillars of DevOps – Essential Foundations for Enterprise Success“, I did not break out security as a separate pillar. At that time, this type of thinking was typical of developers. Security was someone else’s job. Perimeter defenses were deemed sufficient.

    Soon after, I realized that way of thinking was naïve on my part. By the time that I co-authored a subsequent blog, “Nine Pillars of Continuous Security Best Practices,” I added a separate pillar for security specific practices, and also added security practices within each of the other pillars.

    In parallel, DevSecOps became a thing in the DevOps world. The idea of integrating security practices into DevOps makes a lot of sense, because DevOps is the answer to continuous delivery of software, and security needs continuous delivery of defensive solutions. However, simply adding security to DevOps is not a sufficient solution, because DevOps was conceived to address specific problems associated with design, QA and Ops – not security. Simply adding security as another metric for releases is not enough. What is needed is a re-think of how DevOps can be used to deliver continuous security, as indicated in my book, “Engineering DevOps.” This is the same idea behind what is referred to as SecDevOps.

    In my opinion, it is now time for SecDevOps to gain favor over DevSecOps when it comes to integrating security practices with DevOps practices. This represents a much more significant shift than simply putting security first in the name. With SecDevOps, security concerns within the entire development organization and at every stage in the DevOps value stream, are explicitly prioritized over other types of concerns. This makes sense, given the much wider blast radius of security events versus other quality concerns that DevOps was originally designed to address.

    With SecDevOps, security tools and resources are weighted at the highest priority level. SecDevOps and secure coding practices are required training for application developers. Threat modeling is part of the value stream. Security tasks that are required to mitigate security risks are given the highest priority in backlog planning. At each stage in the DevOps pipeline, security concerns rise to the top of the priority list. Release and deployment readiness are weighted at the highest level. In short, SecDevOps explicitly plugs some important security holes that are not covered by DevSecOps. With SecDevOps, security becomes continuous, not just an add-on to DevOps.

    What This Means

    By explicitly plugging some important security holes that are not covered by DevOps or DevSecOps practices alone, it makes sense for SecDevOps to now emerge as the preferred framework to close the gaps between the growing security problem space with the evolving security solution space. SecDevOps offers the required security-first mindset and solves the need for rapid software changes that detect and plug security holes as fast as they are found, and continuously deploys innovative defensive solutions to keep bad actors off their guard.

  • Developer’s Guide to Open Source Spring Cleaning

    Developer’s Guide to Open Source Spring Cleaning

    Spring is here, and after a year filled with record-setting digital transformation and its associated vulnerabilities, now is the right time to give the open source components in your codebase a refresh. For many development teams, today’s open source operations present a ‘mess’ that’s difficult to clean up; often, no one knows how many libraries, third-party components or modules are in use, not to mention their vulnerability status. This can create a significant source of risk and technical debt, making a spring cleaning that much more necessary.

    The good news is that there are some simple strategies and tools that organizations can implement to jump-start the open source spring cleaning process. Once implemented, these systems will help ensure that your codebase is kept up-to-date and clear of vulnerabilities.

    Organizing and Inventorying Open Source

    When embarking on your open source clean-up mission, an ideal first step is to take stock of what’s there. Gathering a list of all the relevant libraries and packages in your codebase, along with version information and where in your code they are used, should be your top priority.

    Decide to Keep or Toss

    There is a strong possibility that some of the components in your library contain vulnerabilities. Be sure to use online databases for a published list of vulnerabilities to easily identify which items may be past their security sell-by date. Consider which ones to update and which to remove altogether if they’re riddled with unpatched flaws.

    Polishing, Dusting and Refreshing

    Polishing your physical surfaces not only makes them look shiny but also protects them from damage caused by light, water or other natural elements. Digitally polishing your open source security posture should involve keeping your code base defended in a similar manner, which means making repeat security assessments as frequently as possible while also keeping the inventory up-to-date so your teams are always aware of what’s being used.

    As a last step in this process, consider dusting off any outdated or existing policy documentation. Give them a spring refresh, as well, so they can account for the changes not only in your open source database but for your entire development team. By ensuring developers are all on the same page regarding policies, responsibilities and best practices, you are effectively setting the stage for the next phase of operational success.

    Keeping Your Open Source Code Clean

    Sometimes a clean-up becomes more substantial than anticipated and requires some extra muscle. Implementing a dedicated tool to assist with this clean-up will not only make the process faster and easier, but it can also lead to fewer false positives and more accurate results based on your choice of reinforcements.

    Software composition analysis (SCA) tools can parse your codebase and discover the libraries, modules or frameworks that are in use, and automatically compare all discovered components against a vulnerability database. Your SCA tool needs two key things to produce actionable results:

    • Access to a curated, high-fidelity vulnerability database. Your time is valuable. It’s well worth getting the most accurate data you can, despite what may be marked “vulnerable” or “safe” in the public domain.
    • Insight into your code. Just because you are using a vulnerable library does not automatically mean your code is vulnerable. What method in the library is vulnerable – are you even using it in your code? If you are using it, are you passing a static value or some input-derived variable? This is a function described as the ‘Exploitable Path’, and it is critical to focusing your clean-up efforts.

    This process will provide a comprehensive list of the flawed modules in use and help you decide what needs to ultimately be kept and what needs immediate attention. With the right tools – and the right data – you can get an accurate, prioritized list of what open source components you should update or depreciate in your code.

    While embedding an SCA tool into your development process and workflow alongside your other build and security-focused tools is essential to stop the accumulation of more risk and technical debt, maintaining the quality and freshness of the source vulnerability data is also extremely critical. While retaining an up-to-date list of vulnerable components seems like a full-time job, baking an open source hygiene process into your workflow can be a key component of your database’s overall maintenance.

    Evaluating your open source components at build time – and then systematically scheduling reassessment scans to catch newly discovered vulnerabilities in previously ‘safe’ libraries – can bake an open source hygiene process into the developer workflow. This will serve to extend the “spring cleaning” mentality to a year-round endeavor. With the threat landscape continuing to rapidly evolve and vulnerabilities rising by the hour, implementing these simple practices could have a long-lasting impact on your open source infrastructure as it stands today.

  • SAST, DAST, SCA: What’s Best For AppSec Testing?

    SAST, DAST, SCA: What’s Best For AppSec Testing?

    According to the most recent Verizon Data Breach Investigations Report, almost 90% of data breaches are driven by financial gain, up from 71% in last year’s report. Most noteworthy, however, is that cloud platforms are particularly at risk, with web application attacks increasing by 43%. As more information is stored within cloud infrastructures, and as more enterprises rely on web applications to maintain business continuity, security teams should consider how security controls can be integrated to DevOps without impacting productivity. However, the security market is often shrouded by acronyms and buzzwords. With the increase in automated security testing tools, such as SAST, DAST and SCA, it’s important to understand the difference between each of these practices, and when to use them in the development cycle.

    DevOps is the convergence of software development and IT operations that aims to continuously build, test and release software. Understandably, DevOps is becoming an integral part of any business as it facilitates delivering new products to end users faster and driving increased revenue. However, failure to secure these digital assets can open organizations to cyberattacks resulting in operational downtime, loss of customer trust and even hefty fines from a regulatory body. The sharp rise of application layer attacks proves that enterprises must proactively address security issues earlier in the software development stage.

    The evolution of DevSecOps takes the concept of DevOps one step further, putting security where it should be: at the heart of the development life cycle, using automation. DevSecOps has helped security professionals understand how they can successfully integrate automated security processes without slowing down development while allowing DevOps to focus on what matters most – building and creating software.

    There are a host of automated application security testing tools out there, each with unique benefits, that are commonly used in the agile software development cycle. This raises the question: what tools should we use, and when, to ensure a secure software development life cycle (SDLC)?

    The Difference Between SAST, SCA and DAST

    The most popular application security testing tools businesses implement in their development cycles are static application security testing (SAST), software composition analysis (SCA) and dynamic application security testing (DAST). Knowing the differences between them and when to use them is crucial to enhance your DevSecOps strategy and secure your web applications.

    Static Application Security Testing (SAST)

    As the pressure to deliver high quality and secure code increases, and DevOps embraces new agile methodologies and technologies, integrated static analysis within the continuous software development pipeline can help detect vulnerabilities early in the software development process from the inside out (white box testing). The benefit of a SAST solution is it doesn’t require a running system to perform code security checks and won’t slow you down like a manual code review or penetration test.

    One aspect that makes SAST unique is that it automatically checks for vulnerabilities within the application source code, byte code or binaries, line by line. This ensures security weaknesses – such as those listed in the OWASP top 10 and the 2019 CWE top 25 – in the proprietary code are detected from the start and during development. As a result, developers can identify the risks and fix any vulnerabilities before they make it into production. They are empowered to shift left and recognize early code defects in the development cycle, a security best practice, which also reduces the cost of fixing security issues.

    However, SAST does have some disadvantages in that it requires access to source code and the underlying framework, making it unsuitable for testing commercial off-the-shelf software (COTS) or working with outsourced development. It is also unable to identify runtime and environment-related issues, which makes it difficult to determine the actual and contextual risks of security flaws and suggest meaningful remediation.

    Dynamic Application Security Testing (DAST)

    Unlike SAST, dynamic application security testing (DAST) is done from the outside in (black box testing), and identifies vulnerabilities when the application is running. DAST tools crawl web pages, locate web services endpoints, inputs and outputs; it requires a working version of a web application for the testing to work. Without looking into the source code, dynamic analysis works to simulate penetration testing to uncover exploitable vulnerabilities and business logic issues from a hacker’s point of view, with reliable results.

    Yet, because this scanning occurs towards the end of the SDLC (running applications), the findings can be substantial and often put additional pressure on DevOps teams to fix these runtime vulnerabilities on short notice, creating friction between the security and development teams. Further drawbacks of DAST include the risk that vulnerabilities can be found too late in the SDLC, resulting in rushed or delayed remediation.

    Software Composition Analysis (SCA)

    Releasing new features on a deadline means that developers often don’t write all their own code. The use of prepackaged open source code is commonplace in modern DevOps practices, and so is the need for security governance. Some SAST solutions now include software composition analysis (SCA) functionality to locate weaknesses in proprietary code and vulnerabilities in open source code.

    SCA tools are designed to analyze the open source components by detecting software licenses, deprecated dependencies and known vulnerabilities and potential exploits in a codebase. SCA enables DevOps teams to manage their security exposure and license compliance while still allowing the use of prepackaged code to speed up development processes. In addition, composition analysis can be run and expanded to newer architectures, including containerized environments, to automate detection for publicly disclosed vulnerabilities within your containers and prevent those disguised in public registries, such as Docker Hub, from being brought into the project.

    With open source components now present in 96% of commercial applications, the ability to spot software supply chain vulnerabilities in development, in and out of the cloud, are vital to reduce web application risks – all of which can be a potential entry point for malicious actors, as we’ve learned from the Equifax and SolarWinds breaches.

    Choosing the Best Application Security Testing Tool

    There is no shortage of application security testing tools. The real conundrum arises when decision makers are presented with a host of various options and pressured to choose. However, these tools are not mutually exclusive. Instead, they form a holistic, almost linear, approach to the entire DevOps pipeline from plan to implementation. What does vary, however, is the application development model. Which tool(s) should you choose for your specific use case? Here are some general guidelines:

    Outsourced Development and Commercial off-the-shelf (COTS) Applications: When it comes to critical business applications for prepackaged code, black box testing is advised for enhanced security peace of mind. Without access to the source code, DAST scanning and/or penetration testing are ideal to test the running application for any critical software vulnerabilities before deployment and to monitor security compliance in the long run.

    Internal Development and Software Customization: For businesses with the resources and infrastructure to create applications in-house, it’s important to build security testing into the SDLC from the beginning. Doing so can help protect against application vulnerabilities including cross-site scripting. For true DevSecOps, arm your development teams with SAST/SCA tools to ensure code security in the ‘code and build’ stage, and apply black box testing (DAST) for security assurance before deployment. Once deployed, regular penetration testing and continuous vulnerability assessment of the underlying infrastructure are also recommended to keep security issues in check with each new release.

    As cyberattacks targeting web applications increase, it is essential for organizations to have complete application security across the SDLC, providing maximum security coverage for development and ensuring they can keep up with business operations.

  • The Basics of DevSecOps Adoption

    The Basics of DevSecOps Adoption

    Embracing DevOps is essential, but keeping the software delivery and deployment pipeline safe has become more critical than ever. While attackers are keen on getting into your Docker containers or Kubernetes clusters, securing your images, pods and clusters can deter attackers. Securing your artifacts, deployment workloads and production environments remains critical today. While we have many tools to get these jobs done, it is vital to understand DevSecOps and its related factors.

    DevSecOps has become a mass movement today. But what makes it so important?

    What is DevSecOps?

    DevSecOps addresses software development security via the mindset that everyone is responsible for security at every stage in the development process.

    DevSecOps is a culture and an evolution where security is given the utmost priority in the software development life cycle (SDLC). Security is everyone’s responsibility, and inspection is done at each stage of the development cycle. Basically, implementing a process for inspecting, scanning and reviewing code by developers at predetermined checkpoints to immediately tackle any identified bugs or vulnerabilities. One of the most challenging parts of the transition from DevOps to DevSecOps lies in building more open and communicative teams.

    Why DevSecOps?

    Using DevSecOps, security becomes an integral part of the planning, coding, building, testing, deployment and production stages. DevSecOps makes continuous testing the default for developers and security professionals to deliver more secure features to the market more quickly.

    In many organizations, most development, operations or DevOps teams see security or security teams as a roadblock to getting things done faster; delaying features. In traditional DevOps implementations, the security aspect was missing, DevSecOps was introduced to stress the priority of security in DevOps.

    The Importance of DevSecOps

    Let’s take Uber’s security breach in 2017 as an example. Personal details and information of 57 million customers and over 600,000 drivers was exposed. Uber paid a $100,000 ransom to hackers in an attempt to get them to delete the breached data. This breach happened because engineers failed to secure and update the credentials they were using on GitHub.

    Similarly, in 2018, Tesla’s Cloud was hijacked and used to mine cryptocurrency by abusing a vulnerability in the company’s Kubernetes cluster. A significant amount of FedEx data was also exposed in the same way, affecting 119,000 individuals.

    Logz.io’s annual DevOps Pulse 2020 survey revealed that, out of 1,000 respondents, only 3% indicated their development methodology as DevSecOps, hinting at the slow pace of DevSecOps adoption in the industry.

     

    Image source: Logz.io

    DevSecOps Best Practices

    Adopt a Shift Left Approach

    Shifting security left helps organizations secure each stage of the development life cycle. This refers to starting testing earlier in the SDLC. The goal here is to enhance quality, cut down long test cycles and reduce the likelihood of unpleasant security surprises at the end of the development cycle or in production.

    Include a Threat Modeling Mechanism

    It is essential to implement a threat modeling mechanism in DevOps workflows since it helps developers and security professionals to view software from an attacker’s perspective. It makes developers more careful while writing code and encourages them to more closely follow code writing and review best practices. Threat assessment or threat modeling will also help identify potential vulnerabilities in system design and architecture, and acts as a crucial part of successful security integration in the SDLC.

    Mandate Developer Training

    Training developers on the importance of security is a critical best practice. Making sure each developer who writes, tests and deploys code understands that security is part of their job description is a priority. Training developers on security best practices, how to embed security, check for vulnerabilities and use appropriate security tools will improve overall security knowledge and increase its application within the organization. 

    Use Available Security Vulnerability Tools

    A vulnerability is considered a flaw in the code, application dependencies, external libraries, licenses used or operating system (OS) packages. There are a number of static and dynamic application security tools that can help the development team to find and address bugs and vulnerabilities as early as possible in the development pipeline. Many are automated to reduce the time it takes for developers to find these flaws.

    Sponsor Bug Bounties

    Bug bounty programs and rewards motivate external and internal security experts to experiment with the platform, analyze, think outside the box and report any major bugs and security flaws found. 

    Security-as-Code

    Security-as-code is the next evolution in DevOps, where security is fully embedded in the development processes. This practice implements security and secure coding practices in the earliest stage of development. With security-as-code, developers will be able to identify vulnerable code ahead of time and add security checkpoints/measures to tackle such irregularities. 

    DevSecOps Tools

    When we talk about DevSecOps, the software development cycle involves multiple checkpoints to identify bugs and any other vulnerabilities and resolve them so that the application works as designed. The aim is to deploy software with quality and confidence, and this is achieved by using various tools at different stages.

     

    Image credits: CatchPoint

    Organizations can choose to use the type of security tools that best work for their needs from their preferred vendor. While the security tools themselves are critical for detecting vulnerabilities in the application through the DevSecOps pipeline, monitoring is also considered an integral part of this process. It not only lets developers analyze and evaluate security vulnerabilities from the end user’s viewpoint, but it can help identify breaches and anomalies after an application is in production.

    DevSecOps Pipeline

    While DevOps focuses on speed and agility, DevSecOps adds a layer of security throughout the software development life cycle. A DevSecOps pipeline adds security activities to every stage of the development process, not simply tacking it on to the end as an afterthought. This is achieved by integrating security checkpoints, controls, policies, tools and techniques from the beginning of the DevOps pipeline until the end. These additions facilitate automated security controls at each stage of the software delivery pipeline.

    Image credits: JFrog

    In his swampUP conference keynote The Divine and Felonious Nature of Cyber Security, John Willis shared some valuable DevSecOps best practices, including:

    • Treat security issues as you would software issues.
    • Adopt a “security-as-code” approach to enable the automation of security.
    • Build security controls and vulnerability detection into CI/CD pipelines.
    • Automate security testing as part of the build process.
    • Proactively monitor the security of production deployments.

    Embedding security earlier in your software development life cycle will yield bug-free features and satisfied customers. Have security checkpoints at each stage and make sure developers understand that security is everyone’s responsibility, including theirs. Manage your software and build artifacts, scanning and securing them at every stage of the pipeline using appropriate tools and techniques. Happy DevSecOpsing!

  • DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More

    DevOps Connect at RSAC 2021: Insightful Talks, Live Q&A, Workshops, Pilates and More

    We are excited to announce the return of DevOps Connect: DevSecOps Virtual Summit on May 19, as part of the RSA Conference 2021. This year, internationally recognized speakers will take a deep dive into “Securing the Cloud Native World.”

    DevOps Connect is a full-day event, featuring four different content tracks, with more than 50 speakers, including keynote presentations, demos, insight talks and featured sessions.

    The agenda features a mix of topics, including cloud security, CI/CD, Kubernetes, GitOps, AppSec, security risks, shift left, open source, case studies covering DevSecOps and more. Attendees will learn how the finance, manufacturing, healthcare and hospitality industries are securing their cloud environments, and how to better secure and monitor their systems.

    DevOps Connect 2021 Lineup

    DevOps Connect 2021 features an exceptional lineup of the most prominent and respected security and DevOps leaders, including:

    • Featured keynote speaker: Christopher Krebs, former director of the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), and co-founder of Krebs Stamos Group LLC
    • Chenxi Wang, founder and general partner at Rain Capital
    • Allan Friedman, director of cybersecurity initiatives at National Telecommunications and Information Administration in the U.S. Department of Commerce
    • John Willis, senior director of Global Transformation Office at Red Hat
    • Cyndi Gula, managing partner at Gula Tech Adventures
    • Alessandro Vozza, principal software engineer at Microsoft
    • Caroline Wong, CSO at Cobalt
    • Thomas Krane, principal at Insight Partners
    • Charles J. Kolodgy, principal at Security Mindsets LLC and analyst at Accelerated Strategies Group
    • Nisha Kumar, open source engineer at VMware
    • Mike Rothman, president at DisruptOps
    • Dave Howell, VP at ZeroNorth
    • Maciej Mensfeld, senior product manager at WhiteSource
    • Matt Wilson, senior product manager at GitLab
    • Erkang Zheng, founder and CEO at JupiterOne
    • Philippe Humeau, CEO at CrowdSec
    • Jennifer Czaplewski, director of product security at Target
    • Al Sargent, senior director of product at InfluxData

    Former CISA director Christopher Krebs, our featured keynote speaker, will be answering questions from the audience during a live Q&A.

    Workshop Friday

    We are also hosting Workshop Friday, as we wrap up the RSAC 2021, offering live workshops designed to be as interactive and hands-on as possible with experts from Google, JupiterOne, Sysdig and Sonatype. These workshops provide professional guidance and training on a variety of topics, including Site Reliability Engineering (SRE), AWS cloud security and protecting against supply chain attacks. On May 21, attendees will have the opportunity to interact with the experts, share their process, get immediate feedback and personal assistance. Each workshop will be live-streamed through our online platform at no cost to attendees. We have limited spots available. Seats are reserved on a first-come, first-served basis. To save your spot, visit the Workshop Friday website.

    A Unique Virtual Environment and a Few Surprises

    The virtual environment features an auditorium with different tracks where attendees can watch the sessions by industry experts. There will be an expo hall lined with booths featuring interactive chats and downloadable resources. The expo hall will be open throughout the event, giving attendees the opportunity to chat with sponsors, including GitLab, Prisma Cloud by Palo Alto Networks, Sonatype, WhiteSource, Sysdig, JupiterOne, Snyk and more.

    We have a few surprises planned to make this year’s DevOps Connect extra special. Take a break between presentations, grab your yoga mat and enjoy a Pilates class by a certified instructor, dance to the music of our featured DJ and check out how to make a delicious cloud drink by a professional mixologist. You can also participate in a raffle to win a copy of “You Can Stop Stupid” by Ira Winkler, author and president at Secure Mentem, and a copy of “Security Yearbook 2020” by Richard Stiennon, industry analyst at IT-Harvest.

    DevOps Connect 2021 offers the best of a physical environment in a virtual context combined with the advantages and convenience that a virtual environment offers.

    Registered attendees will receive a link to access the virtual environment on-demand. To check out the full agenda and to register, visit the DevOps Connect website.

  • The Time for Collaborative Security Is Now

    The Time for Collaborative Security Is Now

    As Bruce Schneier famously said, “security is a process, not a product.” We commonly see companies pour millions of dollars into cybersecurity products and tools to protect against vulnerabilities and lower risks, and yet, more often than not these ample funds are not enough to defend against attacks. 

    Within the span of two decades, we have seen how social power can be leveraged to benefit the masses with applications like Waze, Airbnb, Uber and many others. This same innovative idea could revolutionize the way the cyber world operates by giving security professionals the edge in identifying potential threats. 

    CrowdSec CEO Philippe Humeau recognizes the capabilities of crowd power to invigorate the cyber realm. The community firewall created by CrowdSec uncovers thousands of malicious IP addresses worldwide and helps cripple hacker behavior before it can evolve into major cyberattacks and data breaches. Additionally, the start up just announced it raised $5 million to help take the collaborative firewall to the next level as they work to transform the cybersecurity landscape. 

    In the interview below, Philippe emphasizes the benefits of collaborative, open and transparent security environments in tipping the scales against the hacking dilemma that plagues companies across the globe. 

    Join Philippe at DevOps Connect 2021 on May 19, during the RSA Conference, where he expands on this topic in his session “The Age of Collaborative Security.” Also, learn more about CrowdSec and see a demo of the tool during his spotlight session, “Introducing CrowdSec, The Open-Source Massively Multiplayer Firewall.”

    To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.

  • How to Bring DevOps and Security Teams Closer Together

    How to Bring DevOps and Security Teams Closer Together

    More often than not, there seems to be friction between DevOps and security teams. Despite having the same end goals of creating the most secure code and preventing any potential security pitfalls, these groups of professionals often lack the unity needed to accomplish these end goals effectively and efficiently. 

    In the interview below, Naomi Buckwalter, director of information security and IT at Beam Technologies, addresses this issue and outlines key ways development and security teams can come together to better accomplish their shared missions. She stresses the importance of security professionals reaching out a hand to their DevOps counterparts to teach them how to be security-forward when writing code. However, she highlights how not every security expert has a developer background, so it really takes these two groups of skilled tech specialists working in unison to fill those knowledge gaps for each other.

    Naomi brings over 20 years of IT and security experience to her upcoming session “Six Things Developers Want From InfoSec,” at DevOps Connect 2021, during the RSA Conference. She will expand on some of the key topics discussed in this interview during her talk on May 19 at 4 p.m. EDT.

    To see the full agenda and secure your free spot at the virtual event, visit the DevOps Connect website.