NASA in 'serious jeopardy' due to big black hole in security An audit of NASA's infosec preparedness against insider threats has warned it faces "serious jeopardy to operations" due to lack of protection for unclassified information. A Monday report [PDF] found that NASA has done well, as required, in its efforts to defend and prevent insider threats to classified information – stuff …
About 15 years ago I bought an SGI Onyx system (big high-end workstation) from a guy, who had bought it at public auction but never got it going.
I had to incant some very obscure runes to nuke the PROM password, get it to boot single-user, and hack root, but I did it. And what did I find?
The machine had come out of GSFC - Goddard Space Flight Centre. NASA. And they hadn't wiped it! It has previously been a web server - sprecher.gsfc.nasa.gov - came with a bunch of NASA stuff installed: webservers, internal NASA tools - Earth Observing System Data Gateway etc - user credentials, personnel stuff, Oracle databases - fascinating stuff!
Pic of the thing: https://pbs.twimg.com/media/DuvjScpU8AAhxvk.jpg
Scientists and researchers generally are not that concerned with security unless it relates to regulatory compliance with funding or data that they are using.
It is seen as an unnecessary overhead that stops then doing what they need to do. The same thought process also applies to such things as ensuring the PCs they are using are up to date (not just Windows, Linux has had it's share or holes) and protected.
The one time I had to deal with an encryption ransomware incident, it came in through a research PC in a lab. We disabled the switch port to try and contain things so then they went ape because they could not access the data and demanded that it be fixed NOW. That both PC and server data the had access to were compromised due to user stupidity passed them by.
Never under estimate had incompetent and stupid how really clever people in a different field can be when using IT.
The "PC up to date" issue is often a case in science due to other factors, such as not wanting to (or being able to) interrupt running software, or some old but essential program that can't run properly with some update or newer OS.
That is OK provided said machines are sufficiently isolated, but usually there is no discussion between IT department and scientists on that sort of dirty detail, or you get a conflict problem when some IT manager simply won't accommodate it so it gets hidden so they can actually get on with important work.
The side effects are just as you describe...
Back in the 1990s the ORBS project flagged up a substantial number of machines being used as spam relays inside NASA. Iinvestigation found that most of them were infested with script kiddies - including several quite sensitive machines used as command/control boxes for satellites/space probes and even the main systems controlling the Mars Pathfinder Rovers turned out to be hopelessly compromised
Jay Dyson (aka Cancer Omega - attrition.org) was able to lock down a lot of the network in his day job as NASA security admin as a result of what was discovered, but he faced stiff resistance to securing anything at every step of the way and things backslid considerably after he was forced out in 2002.
NASA's most common approach to network security these days is to require other organisations to compromise THEIR security for NASA convenience instead of doing things properly (they're not the only offender - ESA is almost as bad)
A bit of a niggle, but the Rovers were controlled by the Jet Propulsion Laboratory of Caltech. That institution is under contract to NASA, and thus has to follow a lot of NASA rules and regs, but NASA has at times had a difficult time getting the contractor JPL has doing its institutional IT to follow all of the corporate procedures.
Correct, the Rover controllers were at JPL but the problem was _everywhere_ Jay looked
Pretty much a case of "It's turtles all the way down" - and was a big motivator for NASA to shake up its network security policies
However just as with the Morris worm's previous effect, such shakeups have a limited lifespan before people revert to poor practice and Jay was forced out shortly afterwards when he was falsely accused of invovement in the NYT hack of 2002 (a smear the FBI disproved during their investigation)
If a copy of the US constitution is kept on a server and is the only file on that server, shouldn't that server be public facing? Of course, the data in this case is organized since it's 1 file but, as soon as you put your human resources files on it, well you've become disorganized.
Strange to say but, I'm not sure being disorganized is only a security concern, but it's certainly a security concern. Being disorganized is kind of worse than being insecure to the point where security seems 2nd tier to organization :-/ FWIF, maybe "Misplacement" should be highlighted twice somewhere in NASA's "Data Handling" documents/recommendations.
"in the last three years, NASA users have made over 12,000 requests for elevated privileges"
In many places I have worked, one didn't need elevated privileges. I've regularly found uncontrolled access to sensitive files on sharepoint. Typically, people get put in 'groups' according to their job classification ('manager', 'supervisor', etc), then entire group is given access to resource sets, and no records are kept of the resulting privileges at individual level. So in at least one case every department head had access to penetration test reports, or (the worst case I found) literally everyone had access to them because they were filed in the same resource set as 'policies and procedures'.
They found this at NASA because they studied NASA. Substitute any government agency and they likely would have found the same thing. Substitute any large company and, again, they would likely have found the same thing.
Too often, security efforts focus on high value assets while ignoring public facing assets without realizing their potential as attack vectors.
Too often, this is a management choice in order to reduce costs.
Hi, HildyJ,
Too often, security efforts focus on high value assets while ignoring public facing assets without realizing their potential as attack vectors. ..... HildyJ
The problem is not high value assets you may own or provide administration services to, it is those ignored public facing assets you don't yet own and which be worth owning to have their facility and utility not being used as a punitive and self-destructive element/component in one's own systems demonstrably in deficit of any possible defence or attack against such would then be significantly higher valued assets.
Such has always been/is always the problem that blights and crushes and crashes and trashes traditional flights of progress in service of established status quo agents/parties programming events and matters in order to try and retain and maintain and sustain an exclusive existing command and control.
Such a Vanity though is Absolutely Suicidal .... and gravely to be regarded and wisely to be avoided at all or any cost.
"...unencrypted email containing..."
-- SBU (sensitive but unclassified) data: the lifeblood of defense contractors. Sometimes noted as "controlled unclassified information (CUI)" or the completely unhelpful "For Official Use Only (FOUO)". I can understand NASA having quite a bit of this, and even using unencrypted email at least within house or with NDA-signed contractors, but really they should be using an encrypted file-sharing system like the DoD requires.
-- Personally Identifiable Information: Ah, the HR stuff, which should REMAIN inside HR. All gov't agencies and major corporations deal with PII; handling it is no different than SBU/CUI.
-- International Traffic in Arms Regulations (ITAR) data: RED FLAG. ITAR deals with any item on the US Munitions List and only comes into play when "sending" data internationally (also applies to visitors/phone calls such as to a US citizen, working within the US, for a foreign company/agency). Tracking ITAR releases is the bane of all Export Control departments at every defense contractor. Even hinting that anyone is sending military/materiel-related data internationally is a big no-no for anyone, especially our (supposedly) "civilian" NASA.
Scientists may not bother with security, but in the private sector messing around with these means you're fired, and scientists should at least care about JOB security.
The reason so many NASA users request elevated privileges is that they want to be able to install security updates either before the IT contractor gets around to their machine(s), or prevent the patch installation procedure from taking over their machine during the last two or three hours of submission windows for major funding proposals or conference abstracts.
In one case, a Microsoft Office “upgrade” did exactly that to quite a few scientists in the outfit I used to work for. It’s the kind of thing makes unwilling elevated privilege users out of many non-IT professionals.
"The report also mentions that in the last three years, NASA users have made over 12,000 requests for elevated privileges – just the sort of thing that could lead to more information reaching the wrong eyes."
Or, it could be because they've locked everything down so inappropriately tight that people cannot do their jobs without requesting elevated privs. If these kind of broad brush metrics are high, it doesn't mean users shouldn't be asking for these privs it means you designed your system badly. A good security system is inobtrusive to normal users fulfilling their normal job role, and should only become a regular feature of people's jobs when they start to deviate from that or to an attacker.
Also most elevated privs requests shouldn't be decided by IT, usually it's managers of the area or of the data that should be deciding (and if you've done it right actioning) whether or not an exception to policy should be made.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
