Major Security Issues Remain Within NASA IT Systems
Widespread neglect puts NASA’s networks in jeopardy, Federal News Radio
“The most heralded federal agency is in serious risk of a major cyber attack and no one seems to care. Not NASA executives. Not the contractor hired to protect its end-user devices. And especially not the everyday employees who send rockets into space. Internal documents obtained by Federal News Radio indicate NASA has anywhere from hundreds of thousands to millions of out-of-date patches at every center across the country. Security Scorecard, a cybersecurity company, found as many as 10,000 pings coming directly from NASA’s network to known malware hosts, some lasting weeks, if not months. Multiple sources say Hewlett Packard Enterprise (HPE), the contractor hired to protect NASA’s desktops and end-user devices under a $2.5 billion contract called the Agency Consolidated End-user Services (ACES), is uncooperative at best and negligent at worst, and a major reason the agency’s data and systems are at risk.”
OIG Slams Both NASA and ACES Contractor, earlier post (2014)
“NASA’s lack of adequate preparation prior to deploying the ACES contract together with HP’s failure to meet important contract objectives has resulted in the contract falling short of Agency expectations. We attribute these shortcomings to several factors, including a lack of technical and cultural readiness by NASA for an Agency-wide IT delivery model, unclear contract requirements, and the failure of HP to deliver on some of its promises. In general, these issues fall into two categories: (1) issues related to the Agency’s overall IT governance and (2) management and problems specific to the ACES contract.”
And we wonder why China, Russia & every 16 old pimple faced kids can get into our so-called secured systems
Many times it can be as simple as the email says, “You need to upgrade now, click here.” Not everyone looks at the status bar below to see URL is xmoeqsdfsdgsudlgwe.suspectiouscountry
Yet another example of why the decision to centralize and contract out IT services within the agency was a major blunder, as every technically competent person warned it would be from the beginning.
ACES contract seems to have been problematic for some time, here’s a OIG report on ACES failures from early 2014: https://oig.nasa.gov/audits…
Thanks! added a link.
That’s a very well done article, versus the usual short news fluff. That said, I can say being somewhat urrr…close to the issue, that there are arguably much larger issues here at the root cause level. An ineffective use of resources, strangled by poor processes, which then supports the self justification and inertia to stay with a given contractor, are the more fundamental flaws.
Imagine being given ample resources for some project, but finding that even doing the little things takes a huge effort. Meetings, wait times for approvals, documentation of documentation using tedious systems and manual practices and so on. Well by the time even a small number of the things you wanted are done you’ve burned through all your money! The work that remains to be done – that’s what ends up in these OIG reports. It wasn’t a lack of resources, except in the sense of a lack of resources appropriate to the well known and easily estimated usual squandering of resources to get any little thing done. The rest follows.
This is why NASA benchmarks these costs against other government agencies, not against private sector costs. We love to measure up against other poor performers under guise of comparing apples to apples with similar requirements, and the same type of processes for squandering money.
Another path: http://www.fastcompany.com/3046756/obama-and-his-geeks
It is very easy to call out HPE on this, but I am curious if you were to dig into this, how much is on their end, vs. conflicting orders, priorities, and insufficient resources from NASA? A telling quote from the article: “…you have HPE saying we know it’s in the contract, but we don’t have the resources, and they are getting other priorities from headquarters….”
How many times are they being told from one organization or another, “We can’t apply that patch, it’ll break our software [which we are unwilling to keep up to date]!”? When NASA rolls out a new web page, most of the time, your browser will balk at the fact that the certificates are out of date.
Not sure if anyone recalls the incident where the government bought some “cheap” routers, then discovered that not only were they knock-offs, but had embedded man-in-the-middle attack software that would send decrypted network traffic to a third party (PRC?). Congress, rightfully or not, freaked out and demanded that throughout the government IT Security departments vet every IT purchase, but seem to have forgotten to provide the funding to staff-up this huge new requirement. End result: NASA projects big and small are getting hung up because they can’t buy anything with memory or a network port until it gets approval, therefore everybody marks their request double-plus urgent, therefore nothing gets approved for months on end. So, what is a project to do? Do an end run around IT Security? Sit their on their hands waiting for approval? Try to scream and cry louder than all the dozens of others screaming and crying at IT Sec to get approval?
I wish I could find the document, but I recall a Government IT Security newsletter that quoted a survey where people were asked how many recognize connecting their personal devices to your agency’s internal network is a potential IT Security risk (>80%), but of that those who agreed, most (>60%) planned to continue doing so anyway.
Takeaway: Without serious consequences for violating policy nor support to implement or enforce the policy, is it any wonder policies aren’t being followed?
SSL itself is quite secure but SSL certificates contribute essentially nothing to network security since they are easily purchased nowadays, but are a significant added cost.
Users are continually forced to put up with 12-character passwords changed every 60 days, which contribute nothing to security since the only way a hacker could get the encrypted password file would be if the server is misconfigured, and server configuration is an IT administrator responsibility.
And no, despite frequent claims to the contrary, the National Institute of Standards and Technology does NOT require that passwords be changed every 60 days. In reality this requirement degrades security since a password that must be frequently changed cannot be memorized.