devopsy.kinsta.cloud

Tag: scanning

  • The Scanner We Really Need

    The Scanner We Really Need

    IT has scanners for everything. And by everything, I mean everything. We scan source code for vulnerabilities and data leaks. We scan apps for vulnerabilities. We scan the network for holes. We scan our cards for access … Okay, that last one doesn’t fit, but you get the idea.

    Know what we don’t scan for (and what I propose we start scanning for immediately)? Secrets. Oh, there are apps that include finding secrets as part of their feature set—but only a part—and they only scan for secrets within their domain. What we really need is something all-encompassing. Secrets have a way of turning up everywhere—Git, flat files, databases, source code, email … If it can store text, your secrets are probably in there. The larger the organization, the more true this is.

    Way back in the day, I started working at a company that had mainframe admin credentials stored in a flat file on the network. I am not an InfoSec employee, but I can smell insecurity easily enough and I told them to knock it off.

    I am not mentioning the company by name because this is not indicative of their practices today, nor am I mentioning my position or the market, because anyone interested could then use my LinkedIn profile to figure out who it was.

    In my role there, I had the authority to tell them to knock it off, but they handed me a ready response: “Our network is secure, so we don’t have to worry about it. And we monitor the file … some …”

    The same type of mentality seems to permeate IT today. Security by obscurity is alive and well with regard to secrets, and yet we as an industry know (from hard-earned experience) that it is largely a myth.

    So, we need a tool that can access all the places that secrets might be hiding and ferret them out—I’m thinking like a simple UI that takes a secret and searches for it in all of the configured places—would be perfect. Well, almost perfect. Iteration 2.0 would report on what is accessing the secret in that location.

    Get secrets management. Several markets offer secrets management as part of a toolset, you might even own a product that can do it for you. Then, given the search tool and a good secrets management solution, you could search out all instances and replace access to them. Until iteration 2.0 comes out, you could replace them in a test environment and see what breaks—though we also have the hard-earned experience to know that this isn’t foolproof, so you’ll want to heavily document the change for that odd thing that breaks 20 months from now.

    This is not that difficult a product to design and build; finding where each secret is accessed from would be the hardest part. But that’s still doable with our current dev tools. One of you should build it and get rich.

    But meanwhile, as always, keep rocking it. Secrets stored in not-so-secret locations or not, you’re keeping the company running day in and day out. That makes you the stars of business. Keep up the good work.

  • ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth has extended its namesake software-as-a-service (SaaS) platform for orchestrating DevSecOps toolchains to include integrations with Scout Suite, Aqua Trivy, Gitlab and BitBucket Server and the configuration management database (CMDB) from ServiceNow.

    The company is also adding application portfolio reports to surface the security policies applied to each application, scan results and progress of remediation work and the ability to customize both alerts and vulnerability data compression parameters, such as rate of compression, name and type of vulnerabilities and libraries.

    Finally, filtering and search tools that can be applied to vulnerability datasets have been added.

    ZeroNorth makes it possible to centrally orchestrate and manage both commercial and open source application security scanning tools via a SaaS application platform.

    Christian J. van den Branden, senior vice president of engineering and product management, said that as DevSecOps processes continue to evolve and mature, most application development teams will employ multiple scanning tools because not every tool discovers every vulnerability. This defense-in-depth approach to vulnerability scanning requires an orchestration tool to integrated multiple scanning tools within a DevOps pipeline, he said.

    That orchestration tool also makes it easier for DevOps teams to prioritize vulnerabilities based on their severity discovered by various static application security testing (SAST) and dynamic application security testing (DAST) tools, noted van den Branden. Tools from vendors such as Qualys, Snyk, Palo Alto Networks, Synopsys and WhiteSource are supported across multiple DevOps platforms.

    In general, van den Branden said a “perfect storm” of security issues is forming in the wake of the COVID-19 pandemic. Organizations are rushing to build and deploy digital business applications that will appeal to end users who increasingly are working from home using largely unsecured networks. Cybercriminals are looking to both compromise applications as they are developed in addition to targeting end users with weak credentials that could be employed to inject malware into applications after they are deployed in a production environment, he said.

    Most IT organizations will clearly need to up their application security game, given the sensitive nature of the digital business processes that need to be protected, he added.

    Ideally, DevOps and cybersecurity teams will meld their workflows to achieve that goal. In many cases, however, DevOps teams will simply extend their existing pipelines to address security issues of their own accord as part of an effort to reduce the number of remediation issues they might need to allocate time to remediate after an application has been deployed in a production environment. That becomes easier to accomplish using a SaaS-based platform to orchestrate DevSecOps processes and pipelines, noted van den Branden.

    Regardless of how IT organizations improve application security time is of the essence. More applications than ever are being deployed across an extended enterprise that now stretches from public clouds to multiple classes of edge computing platforms. Defending that attack surface relying on legacy tools and processes is all but impossible if the code deployed on those platforms is fundamentally insecure.

  • Embedding Ownership: A DevOps Best Practice

    Embedding Ownership: A DevOps Best Practice

    From where I sit in the DevOps community, there is often more focus on dev than on ops. Damon Edwards (@damonedwards) of SimplifyOps sought to change that with his talk, “Ops Happens: DevOps Beyond Deployment,” at the All Day DevOps conference.

    Damon dove right into the primary, systemic force behind most DevOps problems: silos. The product development process goes like this: Planning—>Dev—>Release—>Operate. The problem lies in the tendency of many enterprises to place similar functions together. Everyone ends up in a silo. Then walls build up between the silos. Eventually, people only know life in their silo, making handoffs even harder.

    We often find application knowledge and business intent are heavily emphasized on development side but light on the operations side. Likewise, operational knowledge is heavy on the ops side, but light on the development side. Furthermore, development has ownership but limited accountability, while operations has accountability but no ownership.

    While many enterprises are striving toward building cross-functional teams, the reality is that the transformations often stop short of truly integrating operations. The result?  Silos remain.

    So, one has to ask, why is this so hard?

    The reality is that enterprise operations are under tremendous pressure. One side is telling them to go faster and open it up, and the other side is telling them to be more secure and be more reliable. These are often seen as competing priorities.

    To solve this, enterprises need to “shift left” in the product development cycle operations activity as much as possible. They need to do as much as possible during development. For the deploy function, enterprises should be:

    1. Writing/running automated tests
    2. Writing/exercising deploy automation
    3. Running security scanning tools

    For the operate function, enterprises should be:

    1. Writing/exercising automated runbooks
    2. Writing/exercising monitoring/metrics
    3. Operational control (safely!)

    However, shifting operations to the left is much more difficult. How do you do it? Embed ownership.

    Let me repeat: embed ownership.

    First, those who build something define the procedures to fix it, and those who build something fix it when it breaks.

    That sounds simple, but raise questions:

    1. How do you safely and securely give out access?
    2. How do you enable the experts to contribute remediations?
    3. How do you give the experts visibility into operations?
    4. How do you do postmortems days/weeks/months later?

    Damon recommended four steps.

    Step 1: Establish a secure ops portal


    Step 2: Establish a software development life cycle (SDLC) for ops procedures

    Step 3: Connect with enterprise management systems

    Step 4: Make Compliance really happy

    Ticketmaster is a real-life of example of this working at a large, prominent scale. Ticketmaster calls its system, “Support at the Edge” and it involves:

    • Automated Ops procedures written/vetted by the delivery teams
    • Ops remained in full control of what can run and security policy
    • Empowered support teams with self-service ops tasks
    • Empowered developers with limited self-service operations
    • Combined with new incident response model

    Ticketmaster has seen transformative results. Before Support at the Edge, the average mean time to respond was 47 minutes. Now, support at the Edge has reduced that to just 3.8 minutes in addition to decreasing escalations 50 percent and overall support costs 55 percent. Ticketmaster has seen real results.

    Damon has more details in his talk, which you can watch online here. If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free of charge here.

    Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here. This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free, online on Oct. 24.

    — Derek E. Weeks