Tag: data validation

  • Without These 3 Things, You Don’t Have DevSecOps

    Without These 3 Things, You Don’t Have DevSecOps

    DevSecOps adds security to the DevOps software development and releasing paradigm. Everyone thinks this is a great idea, except actual Dev and Ops practitioners, for whom security can be a thankless, stressful time sink. Without the right approach and tools, an organization can run a DevSecOps process that actually contributes little to security. Security simply tags along after development and operations, ignored at every turn. The result is rapidly released, insecure code.

    Industry vendors will tell you they have a DevSecOps solution. You, in turn, may believe you have DevSecOps up and running. However, there can be a big difference between acquiring a DevSecOps solution and fielding a viable, effective DevSecOps program.

    What DevSecOps Isn’t

    1. Every task is manual, and done mostly by consultants.
    2. You send out myriad PDFs or spreadsheets and waste time in meetings.
    3. Your solution or program escalates a lot of security alerts, but never delivers a fix.

    DevSecOps, a Brief Overview

    DevOps, the merging of previously separate software development (Dev) and IT operations (Ops) workflows, has been a boon to businesses. When developers work directly with Ops, which releases and manages the code in production, the entire development-to-release cycle speeds up. This is great news, except when it comes to security.

    Rushing new code into continuous integration/continuous deployment (CI/CD) platforms invites risk exposure. DevOps can easily, but inadvertently, put vulnerable code straight into production on a daily basis. To mitigate this risk, the DevSecOps approach inserts a security function into the workflow.

    This is good, in theory. However, if this is all you have, you do not have a DevSecOps program; you have missed the bigger picture. Without automation, tool integration and results validation, simply injecting security processes into the DevOps workflow might actually make everything worse. Your code will be less secure. The security team will not move quickly enough for the DevOps team, which aims to rapidly release code, and will not always address the security issues raised.

    DevSecOps Requires True Automation

    DevSecOps has to include true automation in the security process. The practice of security pros copying code for security testing and then returning with a spreadsheet of remediation requests simply does not work. Good intentions aside, the Dev team does not want to deal with a long list of security problems, many of which are perceived to be low-risk or could generate false positives. Security is perceived as slowing everything down. There can even be organizational issues that keep the two groups in opposition to one another.

    Instead, code vulnerability assessments should be automated within the DevOps workflow. As code gets checked into Github and then compiled via the build pipeline CI tools, it needs to undergo automatic static, dynamic and interactive analysis. It should undergo a full stack assessment, too. The automated assessment must examine code for vulnerabilities at the mobile or web client layer, the API data transport application network layer and the back end cloud building block app services layer. Automated security testing can analyze microservices, serverless architectures, storage and databases. With this approach, the “sec” part of DevSecOps comprises a “build, set and forget” function. There will be security people involved, of course, but the majority of work is automated.

    This automated vulnerability assessment must then generate alerts and establish a priority hierarchy for their handling. Again, automation plays a pivotal role here, and needs to automatically, and in a meaningful way, triage the long list of findings based on issue severity, privacy concerns and app store blockers. If the assessment produces an overly long list of risks to fix, the DevOps teams commonly tune them out as noise that delays release schedules. However, if the automated process identifies the five or ten “must address” problems, developers are more likely to respond to a realistic, practical set of tasks that create an effective process and resolve issues at the roots.

    DevSecOps Must Integrate With Development and Security Tools

    Security processes are most effective if they integrate with the toolsets used by the DevOps team. These include development tools, cloud platforms and monitoring tools such as security incident and event management (SIEM) systems, as well as ticketing and remediation solutions. That way, security connects directly into the DevOps pipeline; it is neither a digression nor a bottleneck.

    For example, if issues get distributed via ticketing systems, they go directly into developer workflows. Developers might be accustomed to working on issues described in JIRA tickets, for example. If the alerts are suitably prioritized, the developers will likely not perceive the ticket as an imposition on their other work. As security issues appear in JIRA tickets, developers can work on them at a familiar, practical cadence. This improves security and DevOps team collaboration by providing details about issues, occurrences, recommendations and remediation. The results can help remediation of security vulnerabilities be more effective.

    DevSecOps Provides Validation of Results

    A viable DevSecOps program will also provide stakeholders with data about how the program is performing. Reporting and data visualization that documents the results of its vulnerability assessments, and the subsequent remediations, are critical to a successful program. While no application is always perfect on any given release, knowing the risks and having a measurable, clear course of action is critical to a solid DevSecOps program. Successful programs will feature reporting on metrics such as critical issues fixed before production, “business blockers” fixed before rejection, legal costs and regulatory fines avoided and security time and costs saved. Without such reporting and validation of results, there can be no actual DevSecOps. It will be DevOps with some ambiguous security activity surrounding it.

    Application security tools are essential to realizing these three tenets of true DevSecOps and an effective appsec program. The preferred tool should be, as these parameters suggest, highly automated and easy to integrate. It also has to have in-depth reporting capabilities. Armed with the right tools, a DevSecOps group can embrace an approach to the work that is fully automated and intuitively part of the DevSecOps workflow.

  • 5 Steps to Ensuring Validity of Your Business-Critical Data

    5 Steps to Ensuring Validity of Your Business-Critical Data

    Bad data can lead organizations to make mistakes. If your organization isn’t continuously ensuring data is accurate, you can never be sure the business decisions you’re making are smart.

    So, how do you continuously validate your business data without consuming excessive resources? The answer starts with your data professionals, who are entrusted with massive volumes of internal, customer and partner data. A breakdown in database performance can consume valuable time finding a fix. Also, data that’s not properly tested and validated can lead to poor business decisions. IBM estimates poor quality data costs the U.S. economy $3 trillion per year.

    Understanding where to implement data validation tests is a vital step to ensuring accurate data. Data testing is traditionally a development-focused initiative that involves testing smaller units of functionality and asserting what the expected results will be within a development or test database environment. Data validation, on the other hand, focuses on production databases and involves validating larger processes. These processes can include Extract, Load, Transform (ELT) and Extract, Transform and Load (ETL) batches, data and application integration, vendor data feeds and data exports for partners.

    While data validation appears to be a massive undertaking, making small but important changes now will set you up for future success. Consider these approaches to incorporate testing and validation into standard database platform operations.

    Conduct Unit Testing

    Test small units of functionality in isolation from other parts of the system. Your database management team will be able to offer temporary or mock-up data stores that will allow data professionals to test smaller subsets of data.

    Conduct Integration Testing

    Verify units of functionality combine to produce useful results. This will mean taking a careful look to make sure data gets from point A to point B with the intended transformations. Breaking down these processes into bite-sized pieces is the key to testing business rules throughout integration processes.

    Automate Testing

    The keys to building quality test plans include being able to standardize tests, repeat them on a schedule or within a continuous integration/continuous delivery (CI/CD) pipeline and make testing results transparent to stakeholders. Developing an automated process is fundamental to taking a proactive approach as you incorporate testing and validation into regular processes.

    Monitor Production Databases

    Don’t stop at testing and validating data only when updates are deployed. Validating that data is correct should be an integral, ongoing process and will ensure confidence in the data.

    Validate Movement

    Validate counts, balances and totals anywhere data is transferred from one system to another. Monitor that values fall into expected ranges, domain values are adhered to and data heuristics are met. Also, evaluate validation results over time to determine overall data health. Is the data optimized for business needs? Are there holes in the efficiency process that should be addressed immediately? Leverage historical validation results for baselines to identify exceptions and determine a path forward for continuous monitoring processes. Make sure you have the needed capabilities for ongoing testing, validation and monitoring processes for your database environments.

    The journey to a proactive approach to database testing—and away from a traditional reactive or ad-hoc approach—will come with its challenges. Bad data affects companies of all sizes in all industries. Once you understand where to implement data validation tests and start following these best practices for testing and validation, you’ll be well on your way to stopping bad data from compromising your organization’s ability to make sound business decisions.

    — John Welch