With the recent launch of the latest Raspberry Pi, comes a story of “shadow IT” rearing its ugly head at NASA in California.

NASA’s jet propulsion lab in Pasadena lost 500 Mb of data – just 23 files; not the hugest amount of data I hear you cry, but size isn’t everything:  investigators estimated that intruders had at least 10 months to come and go, because the lab had failed to take appropriate steps to prevent external hardware from gaining access to JPL’s network.

NASA isn’t unique in committing such an error, but perhaps it might be worth digging slightly deeper into the supporting reasons as to how this breach took place.

NASA – California

Imagine you’re embarking upon a career in engineering – where is the pinnacle of where you would want to work?  Wherever the biggest rockets are!  You want to work somewhere prestigious; a place that will look good on your resume and that pushes you in your studies to apply your knowledge to take the discipline still further.

Your company might then cosset you; seek to give you the creative elbow-room not to feel stifled, and provide you with a casual budget to go and buy small pieces of equipment to use “as you see fit”.

You are the golden child, who won’t be told what to do by pesky IT admins who are ten-a-penny in California.

Culture

What happened at NASA’s JPL labs didn’t “just happen”, it was allowed to happen – the culture at JPL meant that the kids could go wild in the sandpit, and nobody cared where the sand ended up.  This is not merely a cause for a bureaucratic slap on the wrists, two of the documents contained confidential data on a “Mars Mission”.  The loss of data is bad enough; but where that data ends up could be equally devastating:  NASA has competitors to contend with now; not just Tesla, or other US-based tech billionaires, but the space programs of China, Russia and India.

If you’ve not had the chance, please take the time to get to grips with the OSI 7-layer reference model:  Essentially, what it describes are the layers of technology that convert electricity into a word document and back again (as an example).  If you aren’t identifying mission critical data, then building Info Sec technical protocols around those layers becomes that little bit harder – and subsequently, building operational restraints for staff can come across as a witch hunt.

Info Sec & ITAM should work hand in hand to identify the hardware and software vulnerabilities through change-data; once a network has been established and verified as secure, change-data to that IT estate should set off the required alarm bells to take appropriate action.