staging-devopsy.kinsta.cloud

Tag: devsecops

  • What Biden’s Cybersecurity EO Means for DevOps Teams

    What Biden’s Cybersecurity EO Means for DevOps Teams

    On May 12, 2021 President Biden issued Executive Order 14028, also known as the Executive Order on Improving the Nation’s Cybersecurity. This EO covers a lot of ground, and like all executive orders, it instructs agencies of the U.S. Federal Government to perform specific actions. What it doesn’t do is appropriate funding or create industry mandates. That’ll come later, once some of the plenary stages of the EO are complete.

    Despite this, I’m confident that EO 14028 could be as impactful to cybersecurity as GDPR was to data privacy. I’m also confident that the EO has the attention of business leaders who are trying to figure out what it means to them and their teams—DevOps professionals. While the EO has no underlying mandate to private businesses or those located outside the U.S., it does outline a reasonable set of cybersecurity best practices that can be reasonably interpreted as a call to action for greater transparency.

    In this article I’m going to use the terms supplier and buyer, but I don’t mean to imply that money needs to change hands; only that there are producers of software (suppliers) and consumers of software (buyers). If there is one supplier and one buyer, the software supply chain has one link. If that supplier is also a buyer, the chain has two links. For most software, there are many suppliers; in these cases, the supply chain isn’t so much a length of links but more of a mesh of interconnected links.

    The 2021 Synopsys OSSRA report showed that the average audited application had over 500 dependencies, so that mesh is quite complex—to the point where the security practices used anywhere in the mesh are often obscure, at best. It’s this obscurity that attackers can exploit, which is why one of the key tenants of the EO is transparency.

    As anyone charged with operating a piece of software knows, the security testing performed by a supplier isn’t really obvious, but, as a buyer, you assume the supplier has done the right things when it comes to security. But how do you know? Do you know where the code originated from? Do you know what security targets were used by the supplier? If an attacker is actively compromising the application, how would you know?

    These are all very good questions that are reflected in the EO, to varying degrees. Those questions also belie the reality that suppliers test software. Suppliers do, of course, test their software, but what testing techniques did they use and how effective are/were their tools? And, more importantly, how can you confirm that the mitigations and fixes applied to address identified defects were effective for your deployment scenario? After all, it’s not like every supplier is going to provide you with full access to their source code.

    This is where things become quite actionable for DevOps teams that have embraced the principles of operational feedback mechanisms. For those needing a bit of a refresher, that’s the part of the DevOps mobius where lessons learned operating software are fed back into the next iteration of the development flow. Let’s look at two pieces of operational feedback that are mentioned in the EO: least privilege and log management.

    Log management features prominently in the EO in part because logs enable an understanding of how an application is operating. If a supplier provides detailed information about the log structure and flows, it then becomes possible to build alerts in log aggregation services and SIEMs as indications of unexpected operation. That’s the proactive model the EO embraces—as opposed to forensic postmortem log analysis following a breach—but this requires the supplier to provide insights into the log data indicating that the system became compromised. Of course, to provide that type of data, the supplier must have tested their system software in a manner that allows such a log template to be created.

    We’ve heard that software should be developed using principles of “least privilege” for years, but if you’ve ever been asked to run an application as root or had a supplier not detail the precise network ports required by the application, you know there is still work to be done there. The EO specifically calls out cybersecurity techniques like multifactor authentication and zero-trust network access as ways to achieve granular control over how applications operate.

    It is, however, the coverage of Software Bill of Materials (SBOM) that could have the greatest impact for DevOps teams. In effect, the EO stated that suppliers need to tell buyers the origin of all code within an application. While the EO doesn’t specify the elements of an appropriate SBOM, it does instruct NIST to publish the minimum elements of an acceptable SBOM within 45 days of the EO. When combined with the sections on how build environments are created and managed and the security transparency elements elsewhere in the EO, it’s clear that the EO intends to raise greater awareness of how software is created, patched and maintained.

    In the end, Executive Order 14028 sets a high bar for cybersecurity in general—one where everyone involved in the creation and operation of software will need to up their game. I’ve said for years that it’s impossible to patch something you don’t know you’re running, and that remains true. What must be added is that you also can’t reliably secure something when you don’t know how well each component was tested. The EO is prompting us all to take a step toward solving that problem.

  • Fixing Risk Sharing With Observability

    Fixing Risk Sharing With Observability

    Incentives are mismatched among SREs, SecOps, and application developers. These mismatches create challenges around how and what information is shared across siloed teams. This asymmetrical information creates a moral hazard where one team can shift deployment risk to another team, with no accountability back to the originating team. Risk shifting results in unstable applications, inefficient infrastructure, security issues and poor customer experience. All of that impacts your company’s bottom line.

    Closing the Information Gap

    Observability is positioned as a way to fix the information gap between these disparate groups. Observable systems allow users to ask questions about their behavior in an open-ended way, unlike more rigid monitoring systems. SREs and SecOps teams are already reaping benefits from observability, but mismatched incentives limit its effectiveness. Meeting the observability expectations of IT leaders requires pervasive instrumentation across applications, infrastructure and third-party software. Delivering that level of instrumentation has remained out of reach due to incentive mismatches, as well as human and infrastructure costs.

    The main incentive for developers is shipping code quickly at a reasonable level of quality, meaning a low bug count. This contrasts with SREs, who are incentivized around uptime, performance and efficiency, while the incentives for SecOps teams are around risk reduction and breach mitigation.

    risk sharing observability

    Since SREs and SecOps teams don’t have insight into what developers have changed, it’s easy for performance or security problems to get thrown over the fence to operations. A fresh code push might only include minor changes and be harmless to existing operations. Or, it could replace large chunks of logic across the entire codebase, including adding calls to external and third-party applications. To the intrepid SRE and SecOps teams, one change looks like any other. They don’t get a peek behind the curtain because of the mismatched incentives. DevOps wants to deploy quickly. Waiting on approval from other teams slows down deployments, so comprehensive reviews don’t happen. This doesn’t mean DevOps teams are intentionally trying to sabotage partner teams. They’re simply acting in their own interests based on their incentives.

    The challenge is that one party, the developers, has more information than other parties. That information asymmetry is what creates unbalanced risk sharing. Coping with information asymmetry has led to all kinds of new collaborative models, starting with DevOps and evolving into DevSecOps and other permutations like BizDevSecOps.

    True collaboration has been hard to come by. Early DevOps efforts are often successful, but scaling beyond five to seven teams is difficult because teams lack the breadth of experience in IT operations or the SRE capacity to staff multiple product teams. The change velocity DevOps teams can achieve is often far greater than SREs and SecOps can absorb, making information asymmetry worse.

    If teams can’t maintain high levels of collaboration and communication, another option must be developed. Observability practices, like collecting all events, metrics, traces and logs, allow SREs and SecOps teams to interrogate applications about their behavior without knowing which questions they want to ask ahead of time. However, observability only works if applications, and the infrastructure they rely on, are instrumented. This creates another problem: who does the instrumentation?

    The expectation is DevOps teams embed instrumentation into their code as part of the development process. While that’s a nice idea, there are four reasons this falls short. First, the quality of instrumentation varies. Many log statements are terse and only understandable by the developer that wrote them. The message “In function xyx123!” isn’t helpful to an SRE digging into a performance problem that cropped up in the latest release.

    Second, instrumentation libraries vary by implementation, giving inconsistent results across language bindings. OpenTelemetry is trying to improve this, but its progress is slow and still requires developers to do more work that, if we’re honest, doesn’t benefit them; it benefits SREs and SecOps. Now we’re back to those pesky mismatched incentives and information asymmetry problems again.

    The third problem with instrumentation is the volume of data. Each instrumented application can produce terabytes of data each day. When you have robust instrumentation, the amount of data can be overwhelming, and extremely costly to analyze and store.

    Lastly, instrumentation is isolated to the code your team wrote. That represents a fraction of the code you rely on. Vendor-provided services and APIs remain a black box, limiting your observability into those components.

    Resolving information asymmetry across teams requires two things:

    1. Pervasive, pluggable instrumentation capabilities for all code that doesn’t require developer involvement, and
    2. An observability pipeline to filter, redact and enrich data, then route it to your analytics platform of choice.

    Pervasive Instrumentation

    Operations teams need instrumentation without having to go back to developers and beg them to add it to existing code. They need to turn it on and off as needed, and they need readily consumable data. They also need every piece of data they can get, including packet payloads, insight into encrypted data and so on. This goes well beyond what’s possible with today’s instrumentation options.

    AppScope, a newly released open source project, is a new take on instrumentation. AppScope interposes itself between application threads and system libraries, tracking things like file system access, network and HTTP activity, as well as CPU and process activity. It also provides payload data, and because it sits between the application and encryption libraries, it also gives access to users’ cleartext data. Because it works with any Linux binary, SREs and operations teams can instrument anything, even code they didn’t write.

    Observability Pipeline

    The challenge with pervasive instrumentation is dealing with all the data generated by applications. Network, file system, and other system data can easily swamp destination APM and log analytics platforms, driving up licensing and infrastructure costs. While instrumentation data is vital to rebalancing risk sharing in organizations, you need a way to manage that data intelligently to get value out of it. This is where the observability pipeline comes in.

    An observability pipeline sits between the sources of observability data and its target destinations. By acting as a strategic control point, the pipeline gives users control over how data is formatted, filtered, enriched, and redacted before it is routed to one or more destinations.

    Observability pipelines help SREs and operations teams deal with the flood of instrumentation data by routing low value data to low-cost storage, like S3, while higher value information lands in APM and log analytics tools. Later, if you decide you need the data stored in S3 to add more context to your analysis, you can replay it back through the pipeline and enrich your data set.

    Shifting business priorities are accelerating the pace of technology deployment across organizations, and teams are pressured to deliver faster. This faster pace of delivery pushes deployment risk to operations and security teams that lack visibility into changes developers have made across complex distributed systems. This information asymmetry also increases risk to the business as applications become less predictable and reliable over time.

    Traditional methods of resolving the information mismatch haven’t worked because incentives across teams aren’t aligned. Adopting pervasive instrumentation and observability practices will give SREs and operations teams critical visibility into rapidly changing application and infrastructure environments, without disrupting the developer experience and process.

  • GitLab Acquires UnReview to Further AI Ambitions

    GitLab Acquires UnReview to Further AI Ambitions

    GitLab announced this week it has acquired UnReview, a provider of a tool that employs machine learning algorithms to identify which expert code reviewers to assign to a project based on both the quality of their previous efforts and current workloads.

    David DeSanto, senior director for product management at GitLab, said the acquisition of UnReview is the latest step in an AI strategy that, in addition to optimizing DevOps processes, will eventually unify machine learning operations (MLOps) and DevOps workflows.

    Accessed via the Dev section of the GitLab platform, UnReview will also be employed to manage the overall code review process.

    GitLab

    DeSanto said GitLab is committed to employing AI technologies to automate workflows and compressing cycle times across all stages of the DevSecOps life cycle. The goal is to not eliminate the need for DevOps teams, but rather eliminate low-level tasks that conspire to hamper productivity while at the same time improving application security, noted DeSanto.

    Providers of DevOps platforms are now locked into an AI arms race on two separate fronts. Each of them clearly sees the opportunity to leverage machine learning algorithms and other forms of AI to automate a wide range of processes. At the same time, it’s apparent providers of MLOps platforms are borrowing heavily from DevOps best practices to manage the development of AI models. However, from the perspective of a DevOps team, an AI model is just another type of software artifact. Rather than deploying two distinct platforms, the goal should be to bring the data scientists that build AI models into the larger DevOps community, said DeSanto.

    The current challenge, of course, is the pace at which DevOps and data science teams work. It may take six months or more for a data science team to construct and validate an AI model that needs to be embedded within an application. Aligning the timetable for an AI model with the application development life cycle is difficult to accomplish if neither team has any meaningful visibility into each other’s workflows. As the rate at which AI models can be developed steadily improves, that alignment issue will only become all the more pressing.

    Going forward, it’s hard to envision any application that won’t have some sort of AI model embedded within it. The issue is that, just like any other software artifact, an AI model needs to be updated. As new data sources become available, an AI model is likely to drift beyond the parameters intended. A rapid change in business conditions may also require the replacement of an entire AI model. The same processes that DevOps teams apply to update any software artifact can also be applied to an AI model.

    It’s unclear how long it will take before some type of convergence of DevOps and MLOps inevitably occurs, as organizations look for more efficient ways to manage what will become thousands of AI models. The one certain thing is the longer it takes to make the effort, the more difficult it will become to overcome the organizational inertia that has been allowed to set in.

  • 7 Step Transformation Blueprint for SecDevOps

    7 Step Transformation Blueprint for SecDevOps

    The struggle for continuous software security is obvious, but the solutions are not.

    As I indicated in my prior blog, SecDevOps is the Solution to Cybersecurity, a security-first mindset, coupled with SecDevOps-specific practices, provides an opportunity to achieve true continuous security. But, in reality, how can an organization accomplish SecDevOps?

    This blog explains how to apply my 7 Step Transformation Blueprint to SecDevOps.

    Leadership and engineering solutions require the persistent, methodical application of skills and practices toward leading and designing solutions that achieve business and team goals, including continuous security. While driven by visionary ideals, engineering requires practical, disciplined, progressively refined implementations using carefully chosen dimensions of people, process and technology solutions. At any point in the engineering life cycle, the goal is to achieve a balanced solution while evolving practices towards maturity.

    The seven step transformation engineering blueprint prescribes seven steps for achieving and continuously refining digital transformation methodically, no matter what the goals or current level of maturity are. The seven steps are visioning, alignment, assessment, solution, realize, operationalize and expansion. Each step considers the people, process and technology aspects of the transformation.

    Step One – Visioning

    Top leaders define a strategic vision for the digital transformation for the organization including a motivating vision statement, measurable goals, team values, and major implementation tactics. Identify senior sponsors that will own the transformation at the strategic level. Include key partner organizations that need to be strategically aligned to the transformation. In a SecDevOps transformation, a vision for a security-first mindset and associated SecDevOps practices are called out as the highest priority for implementation tactics supporting the vision.

    Step Two – Alignment

    Leaders and key team members who are most important to the implementation of the transformation align specific measurable goals and tactics for selected “model” applications. Specific measurable goals around continuous security are set in this step.

    Step Three – Assessment

    For the current state of selected applications, capabilities are discovered and assessed, deep-dive assessments are conducted for specific topics, and a current state value stream map is created relative to the organization’s goals. My earlier blog, DevSecOps Practices Gap Assessment, explains my recommended approach for conducting an assessment for security.

    Step Four – Solution

    An expert team performs analysis of assessment data and formulates a future state value stream roadmap including themes, epics and user stories and obtains alignment with key stakeholders. My earlier blog, 9 Pillars of Continuous Security Best Practices, outlines a comprehensive set of practices to consider when building a roadmap for any continuous security solution.

    Step Five – Realize

    Proof of concept (POC) trials are conducted to validate solution choices. Trials of security tools and integrations of those tools into the SecDevOps platforms also would be conducted during this step. The solution is validated with selected applications and use cases. Training is conducted as the solution is deployed to production. Governance practices for the new solution are activated.

    Step Six – Operationalize

    Deployed improvements are monitored and controlled with metrics. Retrospectives are conducted to create actionable prioritized lessons learned for continuous improvement. Chris Tozzi’s article 6 DevSecOps Metrics for DevOps and Security Teams to Share suggested metrics that can be developed and leveraged, both for this step and to drive ongoing improvements as the use of SecDevOps practices expand.

    Step Seven – Expansion

    Once continuous flow (the first way of DevOps) is realized for a select set of applications, the organization can safely expand the solution(s) to other applications across the organization. Further transformation cycles will lead to realization of continuous feedback (the second way of DevOps) and continuous improvement (the third way of DevOps) and apply it to SecDevOps.

    What This Means

    SecDevOps strategies and solutions are complex. The seven step transformation blueprint described in this blog can help organizations build a strategy and implement SecDevOps as an important part of their digital transformation. To learn more about how to apply the blueprint to continuous security (and other key elements of digital transformation) refer to my book Engineering DevOps.

  • Serverless Computing Brings New Security Risks

    Serverless Computing Brings New Security Risks

    Attracted by lower costs and less operational overhead, serverless computing is an unmistakable undercurrent in the world of DevOps. Developers are drawn to the innovation because it requires no architecture to manage while offering continuous scaling for anything from a few requests per day to hundreds of thousands of requests per second.

    More than 50% of the developers using serverless functions today started using the computing model in the last three years. By some estimates, serverless computing is the fastest-growing segment in the cloud services market.

    While businesses are drawn by the opportunity to extend and integrate cloud applications at greater scale, there’s a dark underbelly to this DevOps phenomenon: security. In fact, organizations cite security concerns as the leading reason why they haven’t yet adopted serverless computing. For good reason!

    Serverless functions are introducing a new breed of threats – misconfigurations, code-level risks, injections and weaknesses – many of which are the underlying risk factors for a software supply chain attack. With adoption of this technology accelerating, organizations need security that delivers more than just visibility into these dynamic environments. They also need the ability to detect and block code-level vulnerabilities and misconfigurations that occur during development and through to production. Most importantly, this needs to happen seamlessly and with little to no impact on DevOps.

    Dynamic Environments Create Complex Security Risks

    The nature of applications has evolved, creating a new paradigm of security risk. In serverless environments, code sprawl makes it harder to identify vulnerabilities and patch them before they become business-level risks.

    In a monolithic application environment, an identified vulnerability could be efficiently patched by the developer through upgrading a single package, pushing a deployment and then testing and deploying the app.

    In a serverless computing model, patching and resolving vulnerabilities becomes a lot more complicated, given that there may be several hundred (or more) environments across different providers and regions. So, instead of having to patch a single application, developers will need to patch, deploy and test hundreds of individual functions that rely on that library.

    With 39% of developers saying they’re now fully responsible for security, it means they’ll carry the burden of having to patch an identified vulnerability – often taking them away from development work.

    With Serverless, You Need to Rethink Your Approach to Security

    Given the distributed nature of serverless functions – essentially, the reason for its flexibility and scalability – many existing security tools will provide little to no visibility, nor the control capabilities, for these computing environments. Many of the security attacks that will occur in serverless functions will be a result of misconfigurations and mistakes that happen outside the purview of the security team and due to legacy solutions which don’t translate to serverless architectures. Further, because abstracted workloads create blind spots, attackers will have more room to maneuver undetected.

    Serverless functions will even render some traditional DevSecOps tools less useful. Scanning tools must monitor hundreds of individual repositories instead of a single monolithic repository, while application performance monitoring (APM) tools lack security proficiency and cannot protect from the OWASP Serverless Top 10 risks.

    The challenge for security teams will be implementing solutions in a way that does not modify workloads or require changing business logic — both of which slow development. When applying security to serverless functions, it’ll be critical that the solution can do the following:

    • Go beyond monitoring and actually detect and block vulnerabilities without elaborate or manual steps involved. The scale of serverless functions will make it nearly impossible for security analysts to manage and keep up with every alert they receive. Instead, they need a tool that delivers actual security and can help them block malicious activity without stopping development altogether.
    • Enable a positive security model that provides protection against malicious changes, like zero-day exploits, within the function. This approach gives security teams more control by automatically detecting and blocking anything that isn’t explicitly allowed in a given function.
    • Provide forensic detail from log-level information so security analysts can fully understand the context of every attack with virtually no impact on latency. Further, with the risk of supply chain attacks soaring, security teams need the ability to identify and map third-party dependencies used during runtime.

    For many organizations, serverless architecture is a very different and unique computing environment – unlike anything they’ve experienced or had to protect before now. That reality means that organizations need a fresh approach to securing these environments and will need to look beyond the traditional tools they have in their tech stack today.

    Above all, developers and security teams will need to work together to ensure security is built-in from the start. Otherwise, serverless functions will quickly become a playground for cybercriminals.

  • API Security by Design

    API Security by Design

    “APIs are nothing new,” said Secure Code Warrior co-founder and CTO Matias Madou, but they have recently become more widely used.

    And where they were once a local mechanism, they are increasingly used in a distributed manner, partly because of changes to application architectures. Another reason is that users are increasingly likely to access systems from outside the organization, whether they are customers, suppliers or employees working at home.

    Potentially anyone and anything can access an API, so developers and architects should therefore assume that APIs are exposed, and treat requests accordingly.

    This means addressing issues such as authentication and authorization, and generally ensuring that the only data exposed by the API is the data that’s supposed to be exposed.

    So assume every API call is malicious, suggested Madou.

    Start at the Beginning

    Achieving API security starts with the design and architecture, so jumping in and writing code immediately is a mistake. Unfortunately, starting with a completely blank slate is unusual, and some code will likely already exist. In that case, it is especially important that the design makes provisions for possible weaknesses.

    If you want secure APIs, then ensure that everyone working on the project – architects, developers, testers and so on – are “very security savvy,” said Madou.

    The need to improve skills is often triggered when the company or one of its competitors experiences a problem.

    So teams should work to identify any existing problems, realize they need to proactively avoid the underlying issues, and undergo appropriate training, he says.

    The trouble is, “security and developers are not often the best of friends,” Madou said. So, developers tend to think that security is the responsibility of their security colleagues. But there should be a common goal: making reliable and secure software.

    “Security needs to help developers,” he said. One way of achieving this is to appoint a ‘security champion’ to act as a bridge between the security and development teams. An embedded security person can help developers realize that security is an enabler, not a blocker.

    Help When Help’s Needed

    Embedding communication from the security team into developers’ workflows is another part of the process. Slack is one possible conduit. Security people need to be wherever developers discuss issues. Then, they can take advantage of opportunities to say things like, “it looks like you’re having problems with SQL injection. Here’s some training material that might help.”

    Developers live in their IDE, so that’s where integration should occur. But design such systems to help developers, not to control them. “Developers are people, not robots controlled by machines,” Madou warned.

    Another consideration is that it’s important to avoid unnecessarily interrupting developers. Such systems should therefore predict what a developer is about to do and deliver appropriate guidance.

    For example, if someone codes a database connection, the system could offer the statements that securely retrieve information. Then, the developer can copy and paste them instead of starting from scratch each time. Using new code every time carries the risk of introducing vulnerabilities.

    “It’s tricky to make these systems,” Madou admited, but he predicted they will become increasingly common in the coming years.

  • The Importance of NetSecOps in Network Management

    The Importance of NetSecOps in Network Management

    The IT landscape has changed beyond recognition in the past decade or so. The vast majority of businesses now operate largely in the cloud, which has had a notable impact on their agility and productivity. A recent survey of 1,900 IT and security professionals found that 41% of organizations are running more of their workloads in public clouds when compared to just one quarter of respondents in 2019. Even businesses that were not digitally mature enough to take full advantage of the cloud will have dramatically altered their strategies in order to support remote working at scale during the COVID-19 pandemic.

    However, with cloud innovation so high on the boardroom agenda, security is often left lagging behind, creating a vulnerability gap that businesses can little afford in the current heightened risk landscape. The same survey found the leading concern about cloud adoption was network security (58%).

    Managing organizations’ networks and their security should go hand-in-hand, but, as reflected in the survey, there’s no clear ownership of public cloud security. Responsibility is scattered across SecOps, NOCs and DevOps, and these teams don’t consistently collaborate in a way that aligns with business interests. We know from experience that this siloed approach hurts security, so what should businesses do about it? How can they bridge the gap between NetOps and SecOps to keep their network assets secure and prevent missteps?

    Building a Case for NetSecOps

    Today’s digital infrastructure demands the collaboration – perhaps even the convergence – of NetOps and SecOps to achieve maximum security and productivity. While the majority of businesses do have open communication channels between the two departments, there is still a large proportion of network and security teams working in isolation. This creates unnecessary friction, which can be problematic for services-based businesses that are trying to deliver the best possible end user experience.

    The reality is that NetOps and SecOps share several commonalities. They are both responsible for critical aspects of a business and have to navigate constantly evolving environments, often under extremely restrictive conditions. Agility is particularly important for security teams to keep pace with emerging technologies, yet deployments are often stalled or abandoned at the implementation phase due to misconfigurations or poor execution. As enterprises continue to deploy software-defined networks and public cloud architecture, security has become even more important to the network team, which is why this convergence needs to happen sooner rather than later.

    We somehow need to insert the network security element into the NetOps pipeline and seamlessly make it just another step in the process. If we could automatically check whether network connectivity is already enabled as part of the pre-delivery testing phase, that could, at least, save us the heartache of deploying something that won’t work. And then, if we do need to open new ports, an automated process that could also raise a change request would save even more time. Better yet, if it’s one of those “make this like that” changes, the change could be automatically implemented on the firewalls – in minutes, not weeks.

    With NetSecOps, application developers can get creative without worrying about security slowing them down, and network security teams can sleep soundly, knowing that risk and compliance checks are built in to the continuous delivery process with a full audit trail, so they can even get time back to do some fun stuff.

    If we could do all this with only the rare cases of new connectivity requiring approval by security, the NetSecOps dream could become a reality, allowing fast, high-quality delivery. With NetOps and SecOps working together, organizations can establish a collective approach to network management and security, offering equal opportunity for both teams to present and prioritize issues and agree on the fundamental rules from the start; a match made in heaven.

  • 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.

  • 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.

  • What Data Catalogs Don’t Reveal

    What Data Catalogs Don’t Reveal

    In today’s data intensive world, data catalogs, as the name implies, are simply catalogs of information (some human-entered and some extracted from metadata in systems). The importance of data in the enterprise has grown, and analytics plays an increasingly important role in generating value. So, while it’s important to collect and store and organize all this data, data catalogs are missing a major piece of the puzzle – they fail to draw accurate relationships between data assets and how they relate to (or are calculated from) each other.

    It is like having a catalog that contains a description of all the electronics components in the world, but without an understanding of how to assemble those components into a clock, a radio or even a computer. Or how to diagnose what needs replacing when the device stops working.

    Data catalogs cannot answer a whole host of questions along the lines of, “What are the consequences if I make a change to this dataset?” Even if the information in the data catalog is religiously updated, if a change was, in fact, made, users impacted by that change, whether directly and indirectly, have no way of knowing that a change was made. As a result, risk of unidentified issues is high.

    The table below summarizes the strengths and weaknesses of traditional data catalog products.

    Issue

    Data Catalog Strengths

    Data Catalog Weaknesses

    Data Discovery
    • Collect metadata information from a wide variety of systems
    • Give users flexibility to manually update information
    • Simplify searching for data assets across a wide variety of systems
    • Make it easy to identify the subject matter expert (SME) related to a dataset
    • Rely on manually maintained documentation
    • Do not automatically relate data sets to each other
    • Do not understand how data assets are calculated from each other
    • Fail to identify who uses a particular dataset (and how they use it)

    Data Governance
    • Provide a robust framework for managing the availability, usability, integrity and security of the data
    • Rely on manually maintained user-defined rules for dictating data access
    • Cannot automatically propagate access rules from one dataset to antecedent datasets

    Infosec Compliance
    • Make it easy for users to label personally identifiable information (PII) and other infosec risk data sets
    • Do not automatically infer the implications of data processing on the movement of PII inside the enterprise

    Data Quality
    • Data catalogs do not actually inspect data – so they do not assist with data quality issues
    • Complete failure to identify issues and communicate who those issues impact downstream from a data quality issue

     

    Data Discovery

    Data catalog solutions provide powerful frameworks for collecting metadata and facilitating documentation of datasets. The collection and aggregation of metadata is automated, and data engineers/analysts are, hopefully (but rarely), compliant in documenting their work so others can leverage it.

    Unfortunately, data catalogs fail to identify how datasets and processing rely on each other. There is no way to reliably identify which users access and rely on particular datasets, both directly and indirectly.

    Tasked with this objective, a data engineer can manually answer these questions by searching and analyzing the relevant data processing code. This approach uses expensive data engineering resources, takes time and results in reduced analyst and data engineering productivity.

    Data Governance

    When new data sets are created, the authors must tag the data to control data governance. Not only does this rely on compliance from the author, but the rules must be propagated to determine who can use the newly processed data. How should the rules be propagated? This is a complex issue. For example, the city in an address may be restricted, but aggregates across that city may not be. Defining these rules, in and of themselves, is complex — applying them is even more complex.

    Reliance on data engineers and analysts to comply with data governance documentation and systems for enforcement is error-prone and expensive. Sensitive datasets are at high risk of being exposed.

    Infosec Compliance

    Current solutions to information security compliance rely on:

    • Users manually documenting if their data processing activities use (or produce) infosec-sensitive data.
    • Automated identification of infosec-sensitive data by inspecting the actual data and using algorithms to identify how the data needs to be secured.

    Data catalogs are used to facilitate user documentation of data processing activities to comply with infosec compliance requirements. This process relies on humans manually maintaining documentation and systems (and performing actual data inspection.) These processes present significant security risks in and of themselves, because both data inspection – which itself presents a risk – and skilled manual work is required.

    Data Quality

    Data engineering already has processes to identify when there is an issue landing data in a table. Automated systems are available that inspect data values and make intelligent decisions (some even based on machine learning) about whether or not the data is acceptable. These systems exist outside of traditional data catalogs.

    The question is, who will that problem impact? You must identify who are the immediate users of the data. You must also identify the indirect users of the poor-quality data.

    The current approach to this problem is to have skilled data engineers review all data processing code and manually identify users to warn – this is both expensive and time consuming. Beyond this, the risk is that a user is not identified; what if the error impacts a report that lands on the CFO’s desk and they are not warned?

    Data catalog solutions are good at solving the problem for which they were initially designed – finding datasets that are of interest to data engineers and data analysts.

    The risk in DevOps is that data catalogs are relied upon for data discovery, data governance, infosec compliance and data quality issues that they fail to address in today’s complex data processing environments.