devopsy.kinsta.cloud

Tag: Common Vulnerabilities and Exposures

  • At Some Level, We’re Doing Security Wrong

    At Some Level, We’re Doing Security Wrong

    Years ago, right here in this blog, I pointed out that the worst of gamification was being applied to information security–play the game until you lose. I wish I could say we were past that, but we are not. And I think it is time for us to have a bit of a rethink (as my UK colleagues would say).

    Consider this. Twenty years ago, breaches were relatively common and we were concerned enough to enact laws about data, security, etc. Today, breaches are relatively common. In the intervening years, we implemented more and more security.

    The problem is that our environments—from mainframes to today—have grown increasingly complex. Our mission to make applications more useful and accessible makes them more vulnerable at the same time. And the changes are constant.

    If we were doing this right, breach notifications would be super rare, and we’d all want to know if it was a broken machine or human at fault—kind of like aircraft crashes are handled and reported in most of the world. Instead, we go out to a site like haveibeenpwned to see if we’ve been impacted, shrug and assume that the free credit monitoring service from the last five breaches should have us covered financially, and we move along.

    Internally, there is a post-mortem that closes whatever hole the attacker got through or exfiltrated data through and carry on, knowing full well that a different attack is coming.

    We are currently staring longingly at the bright lights of AI, hoping it can protect us from unknown vulnerabilities going forward. A bit of critical thinking will make it obvious that this is simply keeping up with attackers who also have access to AI and are using it to refine and launch even more complex attacks.

    The problem is that we all see the non-stop changes to attack vectors and architectures and don’t know how we could protect more broadly—and that is the appeal of trainable AI. We hope that it can rapidly generalize from its training to detect previously unknown attacks and, given enough inputs, can computationally detect attacks humans might miss in the sea of data. But that is still a point solution, in my opinion.

    How attackers approach the problem and what tools (both tooling and vulnerabilities) they have available are constantly changing, but the goals are unchanged. And I think we have to adapt our thinking to address those goals instead. Policy enforcement is a step in that direction—but, again, that means we’re protecting against the known.

    I don’t have the answers. I keep thinking of two approaches—airplanes are routed around a ton of threats to get their cargo to its destination safely, and that seems to be analogous to the problem. And hardened fortresses that literally ignore current mentality of “the perimeter is everywhere” and take the core, important bits of applications and lock them away even more tightly than we do today, with single-API access to a given bit and the API is monitored and analyzed constantly.

    But those are both sweeping, drastic approaches, and that may be our problem. Security spaces are merging slowly, but we still have a largely “That’s ops, that’s dev” mentality in security (as just one example of why sweeping overall protections are problematic). So, maybe with merges, the time will come that this is naturally resolved. But we’re not there yet.

    If you think about it, we’ve solved much more intractable problems, as the phone in your hand or the online game you enjoy spending a bit of time on demonstrate—we in IT and Dev are capable of amazing feats if we set clear goals and commit to both developing and implementing a solution. We just need those clear goals, and fighting today’s attack and hoping against hope another won’t come tomorrow just isn’t it.

  • Standardize: It’s Not the Where. Sometimes it’s Not the What

    Standardize: It’s Not the Where. Sometimes it’s Not the What

    In our industry’s attempts to follow best practices that marketers assure us we must have or we are going to lose to our biggest competitor … No, wait, we’ll lose to that startup no one ever heard of … No, hold on, we’ll lose to foreign competition … No, wait … (okay, I’ll stop. You get the picture), many of us have gotten completely unreasonable in our IT approaches.

    Like asking a vendor, “Where can I run your application?” Well, the more “where” options the better, because every organization has different needs. But a vendor has to start somewhere, and you can tell when they get to a certain size because they don’t want to talk about it. “We’re SaaS,” was the en vogue thing to say six months ago; now we’re back to “containers” or even “cloud,” thanks to a whole slew of cloud-first offerings out there. But what all of these vendors really need to be able to say (and a disappointingly small number of them actually can) is, “We run on containers, so we don’t have to care where you deploy us.”

    Those are the types of scenarios that forward-looking enterprises need to start anticipating—the broadest, easiest-to-implement, longest-lasting solutions that can be found. The days of “devs picked this DB no one ever heard of because it was 0.0000001 microseconds faster on a hundred-line query,” need to be gone. Standardize on highly usable tools across the DevOps toolchain from libraries approved for use in apps to deployment technology.

    A big part of this approach right now is my pretty common refrain: Advanced automation. The more a system can do, the more time staff has to do other important things. All forms of testing are finally within our grasp because of advanced automation technology ranging from Kubernetes programmability and controllers to ‘AI’ filtering of results (Side note: What most IT folks currently call AI is not; we need to stop calling it that and give it a more accurate name. Machine learning is better; advanced automation is more to the point, IMO). But whatever you call it, it enables massive pre-release testing. From functional to security, it offers the ability to make these tests useful by speeding up testing and results processing so staff need only look at issues considered critical. No one cares where the test engine runs, just that it can run tests wherever the application resides.

    The same is true for a whole lot of other ‘whats.’ Vulnerabilities are probably the best example. Tools are starting to look for them in an automated fashion. Very few organizations have a comprehensive list of which vulnerability databases a tool must support. Any given organization might have one or two databases in their list, but most just require that the functionality be available.

    So don’t get bogged down in the details, and don’t select five different tools to do the same job on five different teams. Start standardizing again. Oh, standardization won’t last when something evolutionary comes along in the space, but it will leave you less clutter to clean up and more specific expertise in-house.

    And that leaves you more time to keep wowing the business. Keep those systems running smoothly and keep cranking out more useful stuff for the organization. Most orgs show their appreciation these days, but some still do not. In those cases, we thank you for them. We know what you’re going through—we are going through it, too, and yet the lights are still on. Keep rocking it.

  • ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

    ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

    I think we can all recall a time in recent memory where, in a meeting or at a conference, someone has had issues with presentation technology. It happens so often that there is almost an expectation of a clunky experience, at least initially. It stands as no surprise, then, that ClickShare’s seamless app was immediately popular with end-users. For them, there is nothing easier than using a ClickShare application to push a presentation from their laptop, tablet or smartphone over to a big screen or conference room projector.

    Belgian-based digital projection and imaging technology supplier Barco designed their automation platform to work that way, and big business embraced the concept. FutureSource Consulting puts Barco’s market share in conference technology at 29%, with integration into 40% of all Fortune 1,000 companies.

    When researchers from F-Secure revealed in December that the seemingly innocuous automation platform was riddled with security vulnerabilities, it sent shockwaves through the business community. The uncovered security flaws are critical in nature, and could potentially enable any number of malicious activities. 

    Researchers demonstrated how the vulnerabilities could allow remote users to snoop active presentations, create backdoors into secure networks or even configure a spyware distribution server that would infect every user connecting to a Barco device. Suddenly, companies were faced with the prospect of having serious security problems installed directly inside conference rooms and offices throughout their organization. And because of the nature of the vulnerabilities, a single compromised device could support a network-wide breach.

    “An attacker who successfully compromised one unit gains the ability to decrypt as well as produce valid encrypted images for any unit, whether within one family or across families,” wrote F-Secure officials in their report. “Further, such an attacker may gain access to sensitive data at rest such as the configured WiFi PSK and certificates.”

    To its credit, Barco has been extremely proactive in issuing patches and fixes to the vulnerabilities found within its products. Security vendor Tenable recently released a report showing 15 vulnerabilities across eight presentation tools, including Barco. As of February, only Barco has been active in deploying fixes.

    Although some of the Barco vulnerabilities require hardware changes (and these will be a nightmare to deploy, if a firm acts to this degree to secure them at all), many of them can be corrected with software patches. This gives most enterprise users a seemingly good plan to fix their immediate problems, but they are hardly in the clear now. The problems with Barco are just the tip of the iceberg when it comes to dealing with vulnerabilities in well-known hardware and software products.

    The Root of the Problem

    Now that the immediate issues have been resolved, we need to ask how devices with serious security flaws ended up sitting in thousands of conference rooms worldwide, or why they were so poorly designed and programmed in the first place. It’s not like the F-Secure team was uncovering zero-day or previously unknown vulnerabilities. Ten of the flaws discovered in the Barco products were associated with well-known, common vulnerabilities such as code injection attacks. Most already had Common Vulnerabilities and Exposures (CVE) identifications.

    So how did decades-old CVEs get coded, or even hardwired, into modern presentation tools? The only possible answer is that developers either didn’t know about them, or that security was not made a priority as the Barco devices were being designed. Sadly, this is a common situation, and certainly not exclusive to the Barco teams.

    The best time to fix a vulnerability is while an application is being developed, long before it gets sent out to users. The worst (and most expensive) time is after a product has been deployed, or after it’s been exploited by hackers. This can be a hard lesson, and one that Barco will surely learn as its once-impenetrable market share takes a hit following this security fiasco.

    Shifting security fixes back toward the development process isn’t easy, but is necessary in today’s world where even seemingly simple devices like presentation tools are both surprisingly complex, and also networked into everything else. In this environment, security must become an organizational best practice. It doesn’t matter if a company is programming apps for social media or manufacturing smart toasters, security must be considered in every facet of an organization.

    Prioritizing security best practice and making it a shared responsibility is the goal of the DevSecOps movement, where development, security and operations teams work together to code and deploy secure software and products. It requires as much of a change in culture as anything else. The new mindset needs to be that deploying a working product with security vulnerabilities is just as much a failure as creating one that can’t perform its primary function.

    In a healthy DevSecOps environment, anyone touching software should be security-aware, with developers receiving relevant and frequent training to avoid introducing disastrous bugs into their work. If the teams working for Barco had looked at security as a shared responsibility, there is no way that such a large collection of vulnerabilities, including decades-old CVEs, would have made it into their presentation tools.

    The Safe Path Forward

    Nobody wants to be the next Barco, having to explain why well-known security flaws were deployed through their devices to thousands of enterprise networks around the world. To avoid that fate, companies developing software or smart hardware should immediately prioritize security as both a shared responsibility and an organizational best practice. Creating a healthy DevSecOps program will take time and likely also require a shift in culture, but the results will be more than worth the effort. Robust DevSecOps can crush vulnerabilities long before they cause trouble.

    For companies buying products and software, it’s in their best interest to support firms that have embraced DevSecOps. Doing so will go a long way to making sure that the devices and software obtained from them aren’t ticking time bombs waiting to be exploited by increasingly skilled attackers.