• Risks Digest 34.45 (2/2)

    From RISKS List Owner@21:1/5 to All on Sun Sep 15 00:15:12 2024
    [continued from previous message]

    differences that matter to them. It’s not for nothing that WhatsApp is spending millions of dollars on billboards calling itself private, with
    the load-bearing privacy infrastructure having been created by the
    Signal protocol that WhatsApp uses.

    Now, we’re happy that WhatsApp integrated that, but let’s be real. It’s not by accident that WhatsApp and Apple are spending billions of dollars defining themselves as private. Because privacy is incredibly valuable.
    And who’s the gold standard for privacy? It’s Signal.

    I think people need to reframe their understanding of the tech industry, understanding how surveillance is so critical to its business model. And
    then understand how Signal stands apart, and recognize that we need to
    expand the space for that model to grow. Because having 70 percent of
    the global market for cloud in the hands of three companies globally is
    simply not safe. It’s Microsoft and CrowdStrike taking down half of the critical infrastructure in the world, because CrowdStrike cut corners on
    QA for a fucking kernel update. Are you kidding me? That’s totally
    insane, if you think about it, in terms of actually stewarding these infrastructures.

    https://www.wired.com/story/meredith-whittaker-signal

    ------------------------------

    Date: Fri, 6 Sep 2024 17:35:36 -0400
    From: "Gabe Goldberg" <gabe@gabegold.com>
    Subject: The For-Profit City That Might Come Crashing Down (NYTimes)

    There are more than 5,400 of these special economic zones in the world,
    ranging on a spectrum from free ports for duty-free trading all the way
    to the special administrative region of Hong Kong. About 1,000 zones
    have cropped up in just the past decade, including dozens of start-up
    cities — sometimes called charter cities — most of them in developing nations like Zambia and the Philippines. Some have actually grown into
    major urban centers, like Shenzhen, which went from a fishing village to
    one of China’s largest cities, with a G.D.P. of $482 billion, after it
    was designated a special economic zone in 1980.

    Each zone offers a degree of escape from government oversight and
    taxation, a prospect that has excited libertarian and anarcho-capitalist thinkers at least since Ayn Rand imagined a free-market utopia called
    Galt’s Gulch in “Atlas Shrugged.” Today, escalating clashes between the government and Big Tech — like the S.E.C.’s regulatory war on crypto, or the Federal Aviation Administration’s repeated investigations into
    SpaceX — have spurred some Silicon Valley entrepreneurs to seek
    increasingly splintered-off hubs of sovereignty. And with government dysfunction preventing reforms even in wealthy cities like San
    Francisco, locked in a decades-long affordable-housing crisis, and New
    York City, which just lost out on as much as $1 billion when Albany
    scrapped a 17-years-in-the-making congestion pricing plan that would
    have funded public transit, it’s not hard to see the appeal of starting
    from scratch. [...]

    There are about three dozen charter cities currently operating in the world, according to an estimate from the Adrianople Group, an advisory firm that concentrates on special economic zones. Several others are under
    development, including the East Solano Plan, run by a real estate
    corporation that has spent the last seven years buying up $900 million of
    ranch land in the Bay Area to build a privatized alternative to San
    Francisco; Praxis, a forthcoming “cryptostate” on the Mediterranean; and the
    Free Republic of Liberland, a three-square-mile stretch of unclaimed
    floodplain between Serbia and Croatia. Many of the same ideologically
    aligned names — Balaji Srinivasan, Peter Thiel, Marc Andreessen, Friedman — recur as financial backers; Patrik Schumacher, principal of Zaha Hadid Architects and a critic of public housing, is behind several of their urban
    (or metaversal) designs.

    https://www.nytimes.com/2024/08/28/magazine/prospera-honduras-crypto.html

    ------------------------------

    Date: Sat, 14 Sep 2024 10:59:58 -0400
    From: Monty Solomon <monty@roscom.com>
    Subject: ``It just exploded:'' Springfield woman claims she never
    meant to spark false rumors about Haitians (NBC NEws)

    ``It just exploded.'' Springfield woman claims she never meant to spark
    false rumors about Haitians.

    The woman behind an early Facebook post that helped spark baseless rumors
    about Haitians eating pets told NBC News that she feels for the immigrant community.

    https://www.nbcnews.com/news/us-news/-just-exploded-springfield-woman-says-never-meant-spark-rumors-haitian-rcna171099

    [The old World War Two adage: A Slip of the Lip Can Sink a Ship. This
    rumor may have cost some would-be roomers a place to live. PGN]

    ------------------------------

    Date: Mon, 9 Sep 2024 00:49:36 -0400
    From: Cliff Kilby <cliffjkilby@gmail.com>
    Subject: Re: Feds sue Georgia Tech for lying bigly about computer security
    (Northrup, RISKS-34.44)

    If the "hired-gun outsider" declares there's not a reason for 'ssh' to be available (because they're applying rules crafted for Windows hosts), does
    that make it true?

    I can think of a lot of good reasons to disable ssh in an enterprise environment that is primarily Windows.

    With containerization, there isn't really anything to ssh to, and if the
    org is virtualizing under HyperV, you can get console access (HyperV remote manager, unless they renamed it again). SSH would be redundant and the lack
    of specialists who can validate and secure the config would create a vulnerability.

    Also, unless the org has enough linux depth to bind nss to kerberos, you end
    up with dual authority for logins, exposing another vulnerability. The more systems of record, the more likely housekeeping isn't done.

    I know ansible for linux is still heavily dependent on ssh, but puppet, chef (infra) and salt don't use it. Allowing ssh for an org that uses chef infra will tend to having admins oneshot servers via knife-ssh rather than
    updating the cookbooks and having the servers update automatically. This contributes to config drifts and config drifts are another vulnerability.åπππππ

    I rarely use ssh anymore because the enterprise has moved away from it.

    As to having systems admins set or participate in setting security policy. Maybe. I know a little biology but I don't feel it's a good idea for me to
    tell the doc how to set my leg, after all, I'm the one who broke

    ------------------------------

    Date: Mon, 9 Sep 2024 12:34:31 -0400
    From: Dylan Northrup <northrup@gmail.com>
    Subject: Re: Feds sue Georgia Tech for lying bigly about computer
    security (Kilby, RISKS-34.45)

    I can also think of a lot of good reasons. None of them are "because it's
    on this security checklist" and all of them are related to the
    circumstances of the specific host (services running, environment, data sensitivity, etc). Things the system admin responsible for maintaining that host is in the best position to know.

    I commend to you the M*A*S*H episode "Morale Victory". Operating on a
    patient with a leg and hand injury, Dr. Winchester makes a heroic effort to save the leg so the patient can walk again. The hand injury gets less focus
    and results in permanent nerve and tendon damage diminishing the use of
    three of the patient's fingers. Turns out the patient is a concert pianist
    and would have happily amputated the leg if the hand could have been
    restored full functionality.

    Security procedures should never be a "one size fits all" set of rules. Guidelines should be reviewed before they are mandated. Variances should be resolved before implementation and not reverted post hoc. And, most importantly, there *must* be a recognition that the security of a system
    needs to be balanced with its usability and the concessions *must not*
    always be to sacrifice usability for security. There is a lot of nuance
    that, in my and many of my peers' experiences, short-term contractors tend
    to gloss over in favor of simple and briskly delivered audit reviews. It's harder to say "yes" and write the justification for a variance than to say
    "no" and check a box. To say that differently, it's harder to do complex
    things properly than it is to do habitual things quickly. If only the incentives were aligned so that people who can say "yes" are incentivized toward doing them properly, but security compliance is a veritable breeding ground for moral hazards and the person demanding compliance with a policy rarely pays the cost of that compliance.

    ------------------------------

    Date: Mon, 9 Sep 2024 14:03:45 -0400
    From: Cliff Kilby <cliffjkilby@gmail.com>
    Subject: Re: Feds sue Georgia Tech for lying bigly about computer
    security

    I can see I've made an error. My apologies at the attempt at humor. I can
    see that it was misplaced.

    Why did the company hire an outside contractor?
    They failed the audit.

    Why would any manager listen to any employee of an org complain about the
    guy who was hired to fix a problem the org created?
    They won't.

    The results tend towards more contractors getting hired to fix things that employees break.

    Yelling at the contractor, or the policy is misplaced vitrol. ߘ˜˜˜There wouldn't be a contractor setting policy if the org didn't have a problem
    that the org created.

    ------------------------------

    Date: Mon, 9 Sep 2024 01:03:09 -0400
    From: Cliff Kilby <cliffjkilby@gmail.com>
    Subject: Re: Standard security policies and variances

    If your org's variance process is broken, and you've reported it as such:

    Congrats!
    You're now paid to do nothing.

    Bonus points if you can create a variance deadlock for which neither can be approved without both being approved at the same time, with each variance
    going to different process owners.

    If you'd hoped to get work done at work, then my apologies. No work has been done at work since 1952.

    ------------------------------

    Date: Mon, 9 Sep 2024 11:10:18 -0700
    From: Stan Brown <the_stan_brown@fastmail.fm>
    Subject: Re: How Navy chiefs conspired to get themselves illegal warship
    WiFi (RISKS-34.44)

    I had a similar reaction to "cannot be understated". But you missed the
    other one, "becomes even more paramount". It's like "unique": thing can't be more or less paramount: either it's paramount or it isn't.

    I can see I've made an error. My apologies at the attempt at humor. I can
    see that it was misplaced.

    Or mistimed. I am currently recovering from some crud I contracted at a
    recent convention. My humor and sarcasm related abilities have been
    severely impaired. Also, unless it is overwhelmingly obvious, I tend not to attribute humor or sarcasm to someone I'm not familiar with when
    communicating via text. My apologies for being a bad audience.

    Why did the company hire an outside contractor?
    They failed the audit.

    Or they wanted someone "from the outside" to be the bad guy to enforce
    policy. Or the outside contractor *is* the auditor.


    And when the org did not create the problem?
    - In a previous life, my company signed a very lucrative contract with a
    bank. My manager was sympathetic to my team's feedback regarding the worthlessness of some of the policies imposed on us by the bank (through no fault of our own). He largely shielded us from direct interaction with the auditors and worked with my team to "provide necessary evidence for
    compliance" in a way that did not affect the services we ran, nor detract
    from the actual security measures we'd put into place.
    - In another previous life as a federal government contractor, there were
    many, many policies that had no bearing on my team or its services but that
    had to be "applied" in one way or another to insure compliance. This was in
    the early 2000s, so it was generally things like "anti-virus on Linux
    machines" (before there were Linux virii and commercial AV software that
    would fulfill the compliance requirements). In the cases I saw, managers
    and PMs were more than willing to go through the mental gymnastics
    necessary to do what was needed to check the box, even if it had a
    detrimental effect on the service, security, or both. It was easier and
    simpler for the project as a whole to take this approach.
    - In my current life working at a state university, we have policies
    imposed on us by state and federal partners, our vendors, and many
    third-party research partners. In none of these cases do the policies originate from a "problem the org created"; they are imposed by third
    parties for primarily/exclusively legal (aka "compliance") reasons and not technical ones.

    The results tend towards more contractors getting hired to fix things that
    employees break.

    Or auditing software getting installed to validate compliance with the
    owners of the auditing software being in the "moral hazard"ous situation of generating the reports, but not being responsible for running both the
    service that is alerting *and* finding a way for that service to comply
    with the imposed policy.

    Yelling at the contractor, or the policy is misplaced vitrol.
    There wouldn't be a contractor setting policy if the org didn't have a problem that the org created.

    I believe I've presented three counterfactual examples above.

    ------------------------------

    Date: Tue, 10 Sep 2024 10:49:51 -0700
    From: Steve Bacher <sebmb1@verizon.net>
    Subject: Re: Former Tesla Autopilot Head And Ex-OpenAI Researcher Says
    'Programming Is Changing So Fast' That He Cannot Think Of Going Back To
    Coding Without AI (RISKS-34.44)

    The article may be found here:

    https://www.benzinga.com/news/24/08/40540066/former-tesla-autopilot-head-and-ex-openai-researcher-says-programming-is-changing-so-fast-that-he-ca

    ------------------------------

    Date: Thu, 12 Sep 2024 09:20:36 +0200
    From: djc <djc@resiak.org>
    Subject: Re: Moscow's Spies Were Stealing U.S. Tech, Until
    the FBI Started a Sabotage Campaign (Shapir, RISKS-34.44)

    Wikipedia presents this as fact, and it is fact, not mere legend. The chip
    was developed at DEC's Hudson, Massachusetts microchip lab -- I worked in
    that building -- and I've seen a photo of it with the legendary trolling.

    When I worked in the 1990s as a consultant for DEC in Europe, Eastern
    European microelectronics engineers described to me the techniques they used
    to try to reverse-engineer DEC's chips beginning with MicroVAX chips that
    they lifted from black-market systems. (One technique was progressive
    ablation of layers of the chip.) They weren't very successful with that,
    but they succeeded to develop new instantiations of the VAX architecture in discrete components, working from paper specifications and bootlegged
    systems. I saw some.

    Those guys *loved* their VAXes and loved talking about what they had done.

    ------------------------------

    Date: Sat, 28 Oct 2023 11:11:11 -0800
    From: RISKS-request@csl.sri.com
    Subject: Abridged info on RISKS (comp.risks)

    The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is
    comp.risks, the feed for which is donated by panix.com as of June 2011.
    SUBSCRIPTIONS: The mailman Web interface can be used directly to
    subscribe and unsubscribe:
    http://mls.csl.sri.com/mailman/listinfo/risks

    SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line that
    includes the string `notsp'. Otherwise your message may not be read.
    *** This attention-string has never changed, but might if spammers use it.
    SPAM challenge-responses will not be honored. Instead, use an alternative
    address from which you never send mail where the address becomes public!
    The complete INFO file (submissions, default disclaimers, archive sites,
    copyright policy, etc.) has moved to the ftp.sri.com site:
    <risksinfo.html>.
    *** Contributors are assumed to have read the full info file for guidelines!

    OFFICIAL ARCHIVES: http://www.risks.org takes you to Lindsay Marshall's
    delightfully searchable html archive at newcastle:
    http://catless.ncl.ac.uk/Risks/VL.IS --> VoLume, ISsue.
    Also, ftp://ftp.sri.com/risks for the current volume/previous directories
    or ftp://ftp.sri.com/VL/risks-VL.IS for previous VoLume
    If none of those work for you, the most recent issue is always at
    http://www.csl.sri.com/users/risko/risks.txt, and index at /risks-34.00
    ALTERNATIVE ARCHIVES: http://seclists.org/risks/ (only since mid-2001)
    *** NOTE: If a cited URL fails, we do not try to update them. Try
    browsing on the keywords in the subject line or cited article leads.
    Apologies for what Office365 and SafeLinks may have done to URLs.
    Special Offer to Join ACM for readers of the ACM RISKS Forum:
    <http://www.acm.org/joinacm1>

    ------------------------------

    End of RISKS-FORUM Digest 34.45
    ************************

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)