Doug Lhotka

Technical Storyteller

  • Home
  • Cybersecurity
  • State of Security
  • Photography
  • 3D Modeling & Printing
  • About

Opinions and commentary are mine, and do not reflect those of my employer.

(C) Copyright 2019-2023
Doug Lhotka.
All Rights Reserved.
Use of text, images, or other content on this website in generative AI or other machine learning is prohibited.

Security Vulnerability Research = Stock Manipulation?

August 29, 2016 By Doug

Last week a group of “security researchers” teamed up with an investment firm in order to make money shorting the stock just before releasing a report on alleged vulnerabilities.  Let’s look at this novel business model.  Disclaimer:  I am not an attorney.

Anyone doing this needs to be very sure of their conclusions before trying to monetize a security vulnerability in this way.  If the vulnerabilities turn out to be inflated or inaccurate (and that’s currently in dispute), then they’d likely find themselves on the wrong side of both shareholder and company lawsuits for loss and defamation, as well as an SEC investigation for stock manipulation.   That’s a whole lot of hurt – the SEC is not an agency I’d like to cross.

But if we assume that the vulnerabilities reported are real and truly significant, we’re into Muddy Waters (the name of the investment firm) for sure.   Assuming that the researchers had no insider knowledge, and didn’t steal or otherwise illegally gain the information, is it stock manipulation?

Is this any different from someone watching the trucks going in and out of Foxconn to estimate how many new iPhones Apple will sell, and basing stock purchases off that research?  Or any different from someone shorting orange juice futures because they developed a more accurate weather forecast algorithm than is generally available?  If they stole a report (Trading Places anyone?), or were given insider information by a tipster, it certainly is.  But for gathering the information themselves?  I’ll be very interested to see where the SEC draws the lines.

In any case, if any of the researchers are members of ISC2 (and I have no way of knowing), they’re probably on thin ice.  The Code of Ethics includes:

  • Protect society, the common good, necessary public trust and confidence, and the infrastructure.
  • Act honorably, honestly, justly, responsibly, and legally.
  • Provide diligent and competent service to principles.
  • Advance and protect the profession.

I think they’d be hard pressed to justify their actions under that canon.  Maybe I’m just old fashioned, or an overgrown Eagle Scout, but this strikes me as out-of-bounds ethically.  Creative yes, but unethical.  Now we wait to find out if it’s also illegal.

Filed Under: Security

Do you know where your endpoints are?

August 27, 2016 By Doug

The Register recently reported that a quarter of banks data breaches are due to lost laptops and phones.

Let’s look at that for a minute, because it shows that there’s some basic blocking and tackling that needs to be put in place.    I suspect that the vast majority of that loss isn’t due to active attack, rather due to regular loss and theft.  A determined attacker (the classic evil maid scenario for example) is a different situation.  There’s some straightforward solutions that could dramatically cut down on this particular threat.

Have an endpoint policy.

The first step in controlling your environment is to know what connects to it.  The policy should require that all endpoints used for business purposes (including BYOD) be registered and managed by the company.  Staff needs to be aware, through annual security training, that only managed and registered devices are allowed.  The policy keeps honest people honest, and provides rationale for sanction or termination if staff deliberately work around the restriction.

Define acceptable configuration.

An organization should have a set of minimum OS versions allowed on endpoints.  That’s the single greatest risk – running an out of date, unpatched OS with known vulnerabilities (XP and non-current Android versions I’m looking at you).  If it’s out of date, it’s not allowed.  Second, the endpoints need to be configured with basic requirements – user ID, screen lockout, password policies, encryption with key escrow, remote wipe (for mobile), no risky software (e.g. torrents), and so forth.

Technically enforce both.

Assuming that there are policies in place, the organization needs to have the capability to ensure that unauthorized devices cannot connect to the network.   That’s is a whole topic by itself, but it’s also a problem with known solutions.  Hard yes, but not rocket science.

The next step in controlling endpoints is to implement an endpoint management automation solution.  This should include both asset management, patch management, and configuration management – in other words, what is the device, who owns the device, is the device on a current (approved) operating system version, and is it configured in accordance with security policies?

This isn’t rocket science either – while there’s no universal solution across computers and mobile devices,  within each of those there are rock solid options that make this a no-brainer to accomplish.

One key part of enforcement is the ability to prove that a device was in-policy when it was lost.  An encrypted laptop that’s lost is a capital loss, not a data breach.  But it only can be counted that way if the organization can prove that it was in-policy.

A word on BYOD.

I’m seeing a trend away from BYOD being allowed, which is unfortunate.   I like BYOD – I use it myself, because it enables me to do a better job than I could with corporate issued equipment. I get riled up when I hear people complain about the intrusiveness of corporate controls on BYOD – after all, BYOD is an option, not a right. If a user doesn’t like the technical enforcement tools, then they can carry two devices.   But a company can no longer safely allow unmanaged BYOD devices.

In the end…point.

If it’s true that 25% of breaches (a breach is when data has been exposed, but not confirmed to have been lost) are due to lost and stolen endpoints, then that shows a lack of basic industry practices (not even best practices – just average).    It’s only a matter of time before there’s class-action litigation against a company that fails to follow these basic steps.

Filed Under: Security

Can someone bring (more) chaos to an airport for less than $50?

June 8, 2016 By Doug

Last month, according to this article, a Verizon wireless crash disabled wifi at JFK, causing huge backups as agents had to hand-write boarding passes and baggage tags.  It’s interesting for many reasons, but we’ve just learned about a vulnerability at that airport.

If the article is correct, it means that someone with a $50 wifi or cellular jammer might be able to take down operations at one of the biggest airports in the world, and (here’s a movie plot threat), a bad actor could plug it in in an out of the way place, so it could disrupt things for a long time before being discovered.

WiFi and cellular data connections are easy and convenient to implement, but for critical infrastructure like this, they have real risks.  I’d guess that the designers focused on availability in terms of hardware failures, and not malicious intent.

Filed Under: Security

  • « Previous Page
  • 1
  • …
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • Next Page »

Cybersecurity

Photography

3D Modeling & Printing

Recent Posts

  • Cabin Ruins in Montana
  • Grand Canyon HDR
  • Grand Canyon First View
  • Grand (foggy) Prismatic Spring
  • Sunny Day at Grotto Geyser