Do You Really Trust NASA Not to Ruin Your Mobile Device?
Message from the Chief Information Officer: Bring Your Own Device and Mobile Computing at NASA, NASA CIO
“In the coming months, the NASA Office of the Chief Information Officer (OCIO) will be working to develop a formal policy to govern the use of personal devices, also known as “Bring Your Own Device (BYOD)”. Until then, I have directed the OCIO to enroll every personal mobile device that accesses the NASA email system into a management profile that helps to secure NASA data, just like is currently done on NASA’s government issued devices. This change, effective September 10, 2013, will enforce a minimum set of security requirements on your personal mobile device if you wish to directly access NASA’s email and calendaring resources from your device’s email client. This change will only affect mobile devices, i.e., those running a mobile operating system such as Apple’s iOS, Google’s Android, etc. It will not affect laptops, nor will affect any access to email via webmail.”
Minimum Security Requirements for Personal Mobile Devices, NASA CIO
AFEU Memo: Message from the Chief Information Officer: Bring Your Own Device, Ames Federal Employees Union, IFPTE Local #30
“You should assume, if you connect your personal device in this manner, that the agency will be able to read and access any data you have on your personal device and that the agency will retain the ability to remotely erase everything on that device. The union has secured an agreement that employees’ personal phones will not be remotely wiped without prior permission from the owner, and I will keep you posted if that policy is altered.”
Keith’s note: It is nice to see NASA slowly dragging itself into the 21st century. But based on the non-stop trail of IT blunders and damning OIG reports on NASA’s chronic inability to get IT right, I’d be very leery of directly connecting any personal computer to NASA. Do you really trust the same group that allowed all of your personal info to sit on laptops that seem to be stolen on a regular basis?
Have a look at the NASA CIO security requirements that NASA wants to place on what you can and cannot do with your mobile device if you connect it to NASA and what NASA can do to it if you do. You might as well just give the phone to NASA.
– NASA is Taking More Servers Offline – With No Explanation, earlier post
– NASA OIG IT Report Highlights Governance Problems, earlier post
– OIG on Information Technology Security Tools, earlier post
– NASA Still Has Not Encrypted All Laptops, earlier post
– OIG Doubts NASA Can Meet Laptop DAR Deadline, earlier post
– NASA IT Blunder Update, earlier post
– other postings
“Have a look at the NASA CIO security requirements
that NASA wants to place on what you can and cannot do with your mobile device if you connect it to NASA and what NASA can do to it if you do. You might as well just give the phone to NASA.”
If you do not do these on your own accord you are a fool. These are all standard best practices that anyone should do with their personal devices.
Then NASA should give every employee who needs this sort of access the mobile device(s) that they need so as to get the access. People who have worked at NASA for a long time usually do not understand what standard best practices are in the real world anyway – starting with the CIO. When is the last time that NASA hired a CIO with actual real world experience in the IT industry outside of the agency?
Chris Kemp….
OK, I have to give this one a go, too. There are a bazillion outfits that want to sell firms BYOD policy/security packages these days, but it’s not an insane idea to segregate (“containerize”) personal and corporate data on the device. As one list of 10 best practices puts it, “Segregate corporate data from personal user data. Users should not be able to alter core corporate applications and when remote wipes occur only corporate data should be eliminated.”
I’d emphasize the “only corporate data should be eliminated.” Would it cost money to implement such policies? Of course, and it’s in short supply in a sequester year. But the OCIO policy is almost laughable when put side by side with this kind of thinking.
“Good” systems offers a mobile device management (mdm) system for iOS devices which containerize the corporate data and many others have similar systems for other platforms. My experience with those MDMs is that they suck because they are resource hogs and are very clunky for users.
So the NASA IT guys want to get into the act and make things even clunkier.
I’d at least like to hear from the OCIO that they field tested some of those “solutions” and found them to be unworkable. I doubt that that’s happened.
It’s an interesting problem. It certainly makes sense that NASA wants to protect its IT infrastructure. Yet, it also makes sense that people will be afraid of what the security wonks want to do to their phone. The other issue worth exploring is the cost to NASA. Currently there is a push to reduce the number of government issued cell phones in a cost saving move. Personal phones do a nice job of keeping employees connected while placing the entire phone cost burden on the employee. Is the risk from allowing a phone to fetch email off of NASA’s servers really that high? Is it really that much different than using a laptop to accomplish the same thing? Is the risk high enough to justify $300+ additional dollars per year, per connected employee? Modern organizations use modern tools. What is the military doing? The banking industry? NSA?
NASA’s IT management is incapable of doing what everyone else is doing – and the OIG constantly reminds us of this fact. NASA screws up, gets caught, and then creates byzantine responses to problems that they created – and their solutions will never be properly implemented.
What is everyone else doing?
The banking industry, in general, is far more locked down than NASA’s proposed BYOD and other processes. VPN access from company owned laptops only, and all traffic is routed through the VPN. USB storage doesn’t work. OS is locked down (users don’t get admin/root access) and software configuration is fully managed. Little or no local disk access except for scratch: everything is stored on the server via network.
I informed my management today I would be deleting NASA email access from my phone due to the new policy. so now it is up to them to decide if 8-5 while at my desk access to me is enough or if they will have to take on the IT cost for a work provided device.
my issues with the policy:
Requiring an unlock code – I use Pattern lock is that sufficient I am not sure.
Requiring the use of data encryption – not going to bog down my phone with that just so I can check my work email.
Requiring to wipe/factory reset after 10 incorrect logins – I have kids and as it is my personal device there are some apps on there for them, sometimes they don’t get the pattern right and I am not about to risk a factory wipe for their mistakes.
Disallowing Rooting and flashing ROMS – I am not going to allow NASA to dictate I must use Touchwiz, HTC Sense or any carrier Bloat on my phone. I root and flash Cyanogenmod as I please.
No longer allowed on the NASA WLAN – so now I must use my data to make sure my work email/calendar is synced while at work? I guess this also means my personal Chromebook is prevented on the WLAN as well so since I chose to go down to a desktop to help save NASA IT money if you want me to be productive at meetings we will need to talk about NASA procured device or increase in cost of pens/paper/toner/printer paper for all the offline work I will have to do at meetings.
In the quest for mobility and reducing IT costs this policy seems to tack in the opposite direction.
There has to be an easier way for NASA to implement this. Seriously. Why is the rest of the real world able to do this- but not NASA? And what happens when the new iPhone 5S comes out with fingerprint sensor instead of numeric passwords? Oh wait, the government already has your fingerprints 😉
No, there really isn’t an easier way. We struggled with this for a long time. The simplest thing we could do was to turn on certain security settings on devices that connect to NASA Exchange regardless of who owns the device so that we did not have to ban all personal devices. That was an option brought up many times, and I and a few others were quite forceful in rejecting that option.
Let’s clear up some confusion: NASA cannot remotely control your device, cannot read what’s on your device remotely, does not know what PIN you set, and will not wipe your device without you requesting that we do that directly. The settings simply ensure that a reasonable set of vendor security capabilities on each device are enabled. This also protects any personal data on the device. There may be mistakes made in some cases, but there are always risks. If you don’t want these settings turned on, then remove the configuration that allows your device to connect to NASA Exchange, and you will then be able to reverse any of these settings.
Michael did the correct thing with his device and deleted the NASA Exchange configuration on it — he didn’t want anyone requiring his device to have any of the security settings turned on; we do not want any jail-broken devices or devices that don’t utilize a minimum set of security features connecting to NASA systems.
“There may be mistakes made in some cases, but there are always risks.” I love it when you IT guys talk this way.
Finally, a positive comment. I was beginning to think you were a pessimist.
That was not a complement. You IT people are clueless.
As are you. And I think you meant that it was not a ‘compliment’. A ‘complement’ (with two ‘e’s) is a thing that completes or brings to perfection, or a number or quantity of something required to make a group complete.
Yep, you are definitely a pessimist.
So you’ve explained that there isn’t an easier way, but not whether a more complex way was discussed and found wanting: containerization. Was it not considered, rejected because it would involve too much complexity (perhaps different products for different OSes), or …?
Containerization is device-dependent, it’s not something we can levy on a device maker. Some devices are showing up with that ability, like one of the new Samsung devices. iOS devices already have it in the sense that each app is entirely self-contained such that no other app can access it or its data (there are some cross app services such as contacts in iOS though).
The problem is that each device that has the capability also requires that to wipe only specifics apps and data without affecting the rest of what’s on it is done differently for each device as well. ActiveSync does not have the capability to selectively wipe your device, just as Apple’s own remote wipe that you would use from iCloud does not have a selective wipe capability.
Mobile Device Management software may have these capabilities, but we don’t have one in place, getting one in place is going to be very expensive, we have to select one that will work for all the devices we’re seeing here, and to be direct, we’ll get beat up for whatever we select, and we’ll get beat up for not selecting any MDM system, so there is some angst about how to proceed. Plus, do we also manage personal devices using whatever we put in place? That’s going to have to go through legal, unions and everyone else. That’s not going to be a quick fix.
So yes, it was discussed as to how we could just delete NASA stuff on a remote wipe, but without the tools to do that properly we can’t make that work right now (and remember, we will not wipe your personal device without your explicitly requesting us to.)
Keith, this is ridiculous. They are asking people to use standard practices that are not onerous: 4 digit pin, screen lock, remote wipe this is all standard iOS stuff. It is all applied with a simple profile that is automatically added, no muss no fuss. Many people now have government issued phones and tablets that really do not enhance their job performance and we could save a lot of money by allowing people to reasonably use BYOD. For once, this is a very rational policy that makes perfect sense. That is not to say they won’t screw it up eventually requiring the use of PIV cards or something like that, but for now, we should rejoice in a common sense policy. Compared to a friend in the financial industry, this is breath of fresh air…
You clearly did not read the entire memo – about what you can and cannot do with your phone once you connect. You lose the ability to treat it as a personal phone. NASA can also take it away from you whenever they want and can erase things from it. You do not have the freedom to install the software of your choice. You also cannot let anyone else use the phone. Doesn’t sound like a “personal” phone to me – more like a government-issued phone.
A government issued phone that you have to pay for.
We clearly have a different reading of this. I just don’t see where you are getting this draconian view from the bullets on page 2.
First and last bullet say that if you have NASA data on your phone and you loose control of it you should notify NASA and the device may be “requested” for foresnsics. What’s so bad about that? it makes sense so they can understand any risk to NASA systems. You have to delete NASA data before you transfer the phone. Would you leave personal data on the phone when you transfer it? – duh. No jailbreaking, that’s reasonable (and like you said, would a NASA person even know how?). It emphasizes the remote wipe will not be utilized by NASA unless requested by the user. And, nowhere does it say that you can not install software of your choice, unless you consider jailbreaking which is a questionable practice. There is no active NASA monitoring of the device with any software agent. There is only a profile included that is required to connect to the exchange server. This profile enforces the (reasonable) security settings.
Perhaps the only one that is a bit unrealistic is the sharing of the device. But common sense rules here. You wouldn’t leave your webmail open on a computer that other people are using; same idea. Letting your kid play a game on your iphone is not the issue, but sharing a phone with someone where it is completely out of your control is probably not a good idea for many reasons. Or if you do that, don’t save the e-mail password and don’t save much e-mail onboard, or better, just use web mail on the device and avoid the whole problem. The exchange 2010 webmail app is quite nice.
As someone whose household has lost several iOS devices, and had to wipe them remotely, I am happy to have had these minimum security requirements in place. They are like I said, OOTB real people best practices. And yes, I have had a phone wipe itself because someone kept messing with the pin. But it’s backed up, so who cares, easy enough to plug in and restore. It’s not like backing up is hard. Apple and Google services provide this OOTB.
In fact, I am considering giving up my NASA iPhone in lieu of getting my own because I want to have more freedom with it.
Not everyone is willing to use their personal funds to buy a cellphone and then have NASA dictate how you use it to do agency work. If NASA requires that you have mobile access then they should provide you with the device to have that access. If they want you to use your own phone then they should do so in a fashion that allows you to FULLY use that phone as your own when you are not using it for work. I can just imagine how much this will cost NASA. As mentioned in other posts there are existing solutions NASA could easily adopt but no, the IT wizards who continue to trip over their own feet have their own solution. Yet another disaster in the making.
They are not proposing that people MUST use their personal devices to defray costs. The policy is so that people who WANT to use BYOD can. As you mention, if NASA requires the use of a mobile device, they will provide it. In my experience at HQ (I can’t speak for the permissiveness at field centers), it takes virtually no justification for getting a mobile device, it’s just de rigueur. To me *that* is a waster of money.
Also, adding a profile to a mobile device is decidedly a *very* cost effective, lightweight solution (does not require any licensing) and simple to make using existing free tools (I have made them in the past for fun). Compare free/little effort with any commercial MDM solution ($$) and it is not viable from an avaialble money standpoint.
Final comment about this policy: it is aimed at the *majority* of mobile users, just the average person with a personal iOS or Android device, not the folks outside one sigma who root their phones and do all kinds of geeky stuff. There is no way to create rational policy that works for every user. You can not speak rooting and not understanding best practices in the same sentence, you can’t have it both ways.
I agree with other posters that open web standards are paramount. Vis-a-vis mobile applications, NASA has instituted some interesting open architecture for agency mobile applications (WebTads being the best known). I bring this up in addition to my comments on this BYOD policy not as a shill for my employer (I am a HQ employee in program IT, not OCIO – look me up, I use my real name here) rather to point out when they actually do something that makes sense.
Rooting and flashing is not hard nor questionable activity giving NASA IT this much control over your personal device is highly questionable. why does NASA have the right to wipe my whole phone. they want to wipe their email fine, but the rest of the phone data is mine.
Read the memo. NASA will not remotely wipe a personal device unless the owner of the device requests it.
Yes, rooting is questionable and does break much if not all of the security of a mobile device. If you want to run as root on an iPhone for example, you have to jailbreak it. Having root access is tremendous security risk.
The key disagreement here is the “wipe them remotely” part. That should be up to you, based on how you lost the device, whether you’re tracking it, whether you’ve made attempts to send a screen message (“Reward”) to whoever has the device, and so on. It’s _your_ decision.
It’s worth pointing out that in iOS, at least, even the ability to set a passcode is an _option_ out of the box, not the default, and autowipe on a specified number of passcode failures is definitely _off_ by default. Calling those “OOTB best practices” is possibly correct (they may or may not be “best practices”) but maybe unintentionally a bit misleading, since they’re only options out of the box, not default settings.
Real security always depends on the user and what they do or don’t do, not just on policies. After all, the new policy doesn’t change at all the ability of a users who don’t want a NASA policy for Exchange push mail to read their NOMAD mail in a Web browser on a totally unsecured device. Does that make sense?
Frankly, I believe that the policy is motivated at least in part by a misunderstanding of how some NASA employees use NOMAD. The assumption appears to be that everyone wants push mail because they yearn for the days when a buzzing Blackberry in their pocket gave them a sense of importance. Maybe that works on some floors of HQ, but ay least some of us older fogeys want to read e-mail when we have the time to read it, not when a sender (the boss?) wants us to drop whatever we’re doing (our job) to read…. yet another retirement party flyer in a Powerpoint attachment.
Read the memo. Remotely wiping your personal device is up to you.
“Your personal device can be remotely wiped in the event it is lost or stolen (NOTE: NASA will not utilize this capability unless explicitly requested by the user).”
Read the memo NASA says that it can wipe your device. They do not say that they will ask you first.
“Your personal device can be remotely wiped in the event it is lost or stolen (NOTE: NASA will not utilize this capability unless explicitly requested by the user).”
The portion in parentheses is in the memo; it’s not something I added here. I’m assuming English is not a second language for you, so either you really aren’t comprehending a straightforward sentence in English, or you’re trying to stir the pot. But here’s my English into English translation for you:
We will not wipe your personal device remotely without you, the device owner, directly and explicitly making that request to us.
That’s it. There truly is nothing further I can do to help you understand this.
I have probably been speaking and writing English longer than you have. Indeed, I was once a professional interpreter translating English into and out of another language.
Your point?
You seem to be missing the rest of the statement – the part that says that wiping might still happen – by accident. Given the huge goof ups that NASA IT has made of late …
I don’t see the statement you’re referring to in the memo; maybe it’s in the FAQ. Maybe I need English lessons.
We are stating what the minimum requirements are to connect to NASA email for personal devices, and we are implementing ways to ensure that the minimum requirements that we can enforce, are enforced.
There are risks which could impact your personal device, including having the device wiped accidentally. I don’t believe that particular risk is high, but it does exist and if you don’t want to accept the risks or you don’t trust NASA is competent enough to not screw up your personal device, then don’t connect it to NASA’s email system via ActiveSync. That is the choice.
I know that upsets some people, and I know it will likely reduce the number of people using personal devices to read NASA email. I don’t want anyone messing with my personal stuff either, but NASA’s email system isn’t our personal stuff, and though I often don’t agree with things we do w/r to NASA IT, I think this policy is a reasonable balance between security and usability. I have two personal devices that are configured to connect to NASA email via ActiveSync that I’ve been using for years now.
Maybe one day we’ll get to a point where people don’t make mistakes; when we get there, we likely won’t need this policy. Until then, I advise good backups or not connecting your personal device if you really don’t trust us or you don’t want to accept the risks, or you don’t like the settings we’re enforcing.
I think we’ve flogged this horse to death, so I’m done commenting on this topic on this site. If anyone within NASA or otherwise still has questions, concerns or wants to gripe about this, and the memo and FAQ aren’t satisfactory to you, contact me directly and I’ll do what I can to help ([email protected]).
Have a wonderful weekend.
/s.
You don’t even read your own agency’s memos on the topic? Not a good sign. http://spaceref.com/news/vi…
Confusion resolved.
The ‘Agency memo’ you refer to above is not an Agency memo; it’s not even a memo. It’s an Ames Centerwide announcement intended for employees at Ames and not something that would be sent to me as I’m a Headquarters employee. I would hope you’d not expect me to have read things not intended for me, not sent to me, and that I had not seen online (yet).
I think you may be conflating the Minimum Security Requirements for Personal Mobile Devices (MSR-PMD) memo with the Ames Centerwide announcement. The language about “wiping a personal device — accidentally” is written in the Ames Centerwide announcement, which is why I wasn’t finding it in the MSR-PMD.
/s.
What was the other language? Gibberish?
American Sign Language.
Sorry, I should have said “Auto wiping.”
I don’t know if Android has implemented this yet, but iOS 7, as has been known for some months now, will offer the ability to lock access to the device remotely or on too many bad entry code attempts (thus preventing thieves’ wiping the device), rather than auto wiping. The owner, provisioner, and law enforcement will still be able to track the device, but the criminal will no longer even be able to enter a code (or, presumably, a fingerprint on the 5S). I hope the OCIO is agile enough to change the policy in the next few months to take advantage of this less drastic approach to possible theft.
It’s worth seeing the security features added to iOS 7 (and once again, I assume Android will follow suit) specifically for BYOD concerns:
http://www.csoonline.com/ar…
The model is containerization at the app level: e.g. if the Agency or its policy detected intrusion, it could turn off access to Exchange mail, without affecting personal mail from other servers. I realize it may be a while before app developers release new versions to make use of this per-app policy opportunity, and I hope the OCIO will keep reexamining its policy.
Read the memo. No, we can’t take it away from you, ever. We can only request that you provide access so we can figure out what happened in event of a security incident: “The owner of a personally owned mobile device may be **requested** to provide access to the device for forensic examination …” If you refuse access, then I guess we won’t be able to use what we find to figure out what happened.
Read the memo. No, we can’t erase things from it. I can’t find any language in there that says we can. If you find it, please correct me.
Read the memo. There is nothing in the memo that prevents you from installing software you want on the device. The restriction is that you not jailbreak the device to do so.
I use a pattern lock not a pin (my next phone can use trusted bluetooth device to stay unlocked which is probably an even bigger violation of this policy), that doesn’t seem to be allowed. and since it is my personal phone the kids sometimes use it. if they get the pattern wrong having NASA wipe the whole thing (not just their precious email) is a risk I am not willing to take.
BYOD was a way to voluntarily push IT costs to the individual, but this policy is going to make the managers decide do they need to shoulder the NASA IT costs to reinstate the digital leash for those deemed critical.
Yeah, it’s a risk having your kids try and unlock your device and end up having it wiped. Don’t you back up your device? What if you lose it, or it’s stolen? Isn’t that really the equivalent of having it wiped since without a backup, your data is gone? No one expects to get into a car accident, but you do wear your seat belts, right?
Again, if you are an example of the NASA IT team’s bedside manner then you should expect people to doubt what you say. Your job is to support these people – not lecture them.
This policy should be a good incentive to device owners to back up their device contents, but the trend the last few years has been one of liberating the device from the desktop or laptop. Some people will backup their device contents to the cloud (is _that_ OK by the NASA data at rest policy?), and some, alas, will never back up anything but their music.
Bottom line: I wouldn’t count on users backing up their devices. Not smart, but real users do things like leaving laptops with unencrypted PII in the trunks of their cars.
I have to comment on this comment. NASA needs a BYOD policy, but this is not it. Some of us have been trying to push for months for such a policy, but it took the OCIO’s draconic action to get any management attention.
Wiping my personal content from my personal mobile device is not within NASA’s purview. The Agency has no legal right to do so. (I don’t know about Android; Apple has patented a feature that can replace remote wipe with remote full “disk” encrypt, with a predetermined passphrase not held on the phone, on exceeding the incorrect passcode entrance threshold, but it’s not in the current mobile OS). NASA certainly does have the right to ask me to stop using a personal device for mobile e-mail, but….
NASA and any other employer who is depending only employees to use personally owned devices to be accessible 24 x 7 is getting not only free work, but getting the employees to pay for the device and the service as well. This is poor recompense.
If my job required it, I would be willing to carry a NASA-owned device as well as a personal one, but I never keep NASA e-mail on my device as it is — I delete them as soon as I’ve read them (or usually, since most of it is the normal management bumf, just the subject line and first sentence), and I can do that securely because (1) I used NOMAD IMAP instead of Exchange push mail and (2) without ActiveSync, there is no PKI on my iPhone, so encrypted messages received by my phone remain encrypted. And my current job does not require an ACES phone (thankfully).
But let’s just look at two obvious faults with the silly OCIO policy: (1) Little kids are great at monkey-see-monkey do. They watch Mom and Dad “play” with their mobile devices all day and night, and are only too happy to keep mashing keys, again and again, in an attempt to enter the passcode (win the game). I wish I had a buck for very device that gets wiped because a small child gets ahold of a device with this “policy” on it. (2) “Apple picking” and similar thefts of high-popularity Android devices (HTC One, &c.) have become so common in large cities that a nationwide police task force has met with manufacturers to try to find a way around it. If someone grabs the device out of your hands as you’re staring at it in {the Metro, the street, a coffeeshop line, wherever), it’s NOT screen locked and a 15-minute lockout period is a long time for reading NOMAD and any other e-mail on the device. That includes PKI-decrypted message content. Not to mention that if the theifl can get clear away within 15 minutes, he or she can sync the contents of the mobile device to a computer in that time.
I could rave on about how BYOD policies should be formulated by involving stakeholders, but the NASA OCIO is clearly not about to involve the actual users in any decision-making process. After all, the bureaucrats would then be faced with technically knowledgeable users pointing out the holes in the plans and suggesting alternative solutions. No, top-down is much better.
The iPhone was introduced six years ago. Before that time, if I wanted official e-mail contact while out of the office and not at home, I used a laptop. I suspect laptop sales to NASA are about to surge. But NASA will no longer be able to contact me when I’m on my own time and not schlepping a laptop around. I hope the Agency does not suffer from resetting the clock to 2007 and ending their enjoyment of our working for free, on our own time. For the mission-operations-minded folks, some of us still use secure, operational (the emphasis is on operational) mailservers rather than NOMAD for the truly critical communications. We’d never trust that to NOMAD in any case, and to be fair, it’s never advertised itself as a secure, mission-critical service.
BRAVO!
Read the memo. “Your personal device can be remotely wiped in the event it is lost or stolen (NOTE: NASA will not utilize this capability unless explicitly requested by the user).”
Should I retort, “Read your own memo?”
The ActiveSync policy being rolled out will auto wipe the entire contents of your personal device if there are ten unsuccessful attempts at entering the unlock code, whether entered by a miscreant or your toddler.
And I’m sorry, but your own memo is strongly imbued with “We know best,” which I would argue is inappropriate in an engineering organization such as NASA that stresses critical thought.
Sure, retort away. But I was talking about remote wiping, not auto wiping after 10 failed attempts. Yes; it’s required for NASA issued devices that after 10 failed PIN attempts, the device auto-wipes. The reason we have to do that for personal devices too is that ActiveSync cannot distinguish between NASA and personal devices and is not able to selectively push only certain things to some devices while pushing other things to other devices. It’s all or nothing until we can get a competent MDM capability up and running. If that were not the case, I would have lobbied very hard to prevent the 10 failures autowipe issue. Yeah, I probably would have lost, but in this case it wouldn’t have changed the outcome.
The whole strategy of integrating software clients on personal devices with NASA servers is technically nonsensical. Communication should be defined by interfaces, not devices. All NASA communication with personal devices should be by fully compliant web interfaces. There should be no requirement for any specific software on user devices. This doesn’t preclude android apps, it simply means they are not required.
Compare this with the reality. Training is frequently behind because the proprietary java-based web training system is only partially compatible with Microsoft’s proprietary IE and incompatible with any open-source browser, even though its functionality is nothing that couldn’t be done with ordinary html and maybe a little AJAX.
Regarding security, obviously the user should be responsible and not put social security numbers on Facebook. But the idea that software (i.e. “data at rest”) can protect against personal mistakes and carelessness is pretty silly. Apple depends on individual responsibility and has very good security.
I think NASA’s policy is geared to people optionally using their devices to access NASA services.
Many private companies are going in a much less savory direction – _Requiring_ employees to provide their own device or take over the responsibility for a company device service and still enforcing policies that infringe on personal rights.
Here’s one such:
http://www.cio.com/article/…
Here’s another dealing with the fallout:
http://www.cio.com/article/…
The answer for onerous BYOD mandates may be to have a high quality smartphone for personal use and an older device for corporate use. Yes, it is stupid to have to carry two devices but it’ll be a cold day in heck before I let my employer get away with this nonsense.
As someone who has been BYOD’ing at NASA for several years, I think this post and a lot of comments are exhibiting a flair for the overdramatic. And I’m a privacy nut.
I’ve used Android, Palm, iOS, Windows, and OSX to connect to NASA’s servers (Exchange, VPN, other services) over the years and have never had a problem. Rooted and jailbroken. Things just work. I get a new phone, I put in my Exchange credentials, I have my mail and calendar. Sure, I run into some snafus with Mac-PC handshakes but that is normal regardless of what environment you’re working in.
There is no way for NASA to remotely wipe or otherwise access my device without my saying so. There is no way for NASA to verify if I am enacting the security measure (passcode, auto wipe, etc) that they say they require. Nor have I ever been asked to verify, or even asked if I’m taking those measures.
To me, this is NASA covering their ass in the event you misuse their services or don’t perform the due diligence to ensure that protected information does not become publicly available. Then they have reason to fire you and shift the blame.
It’s a tough issue, I recognize that. However – I think this is the right way to do it based off my personal experience that counters the Draconian view being painted in these posts. As others have mentioned, if you go work for the military, or the banking industry, you are *much* more hamstrung in terms of using your own device and just IT resources in general.
not sure last time you set up a mobile phone, but it asks for permission during checking incoming server settings (when it pings mail01.ndc) and requests permission for remote wipe if you don’t agree setup fails. Plus there is an option in webmail right now to remotely wipe your mobile device under options>> mobile phone. Under Exchange Administration Center. the new changes to the policy is auto wipe if pin lock wrong 10x and no root/ROMS plus use of VPN on WLAN.
I suspect the auto-wipe after “nn failed pass code attempts” on the BYOD may already be enabled as it is a feature of ActiveSync. See:
http://images.apple.com/iph…
I have confirmed, as you have as well, that I can remote wipe my BYOD from OWA (Webmail), This capability is also a feature of ActiveSync.
Does anyone know if this “auto-wipe after nn failed pass code attempts” is in effect TODAY as I am suspecting? It would be nice to know if this is the case as this has not been communicated to the community! At least not effectively. I don’t recall getting asked for permission for the auto-wipes when I set up Exchange on my BYOD iPad late last year – however my memory may be faulty.
Thanks,
Forrest Lumpkin
the 10x is not implemented now on my android devices and I expect I will get kicked off the exchange servers on sept 10th since I am rooted and running Cyanogenmod Android not Samsung Android on my phone. plus I use pattern lock not pin which is not mentioned as being allowed.
Thanks for the info. The memo does not make that clear as some of the things discussed such as the requirement for a pass code and the 15 minute time out for the screen lock are already here for a BYOD today.
they maybe already here on iOS but not android. I can turn off screen lock and change time as I please right now.
I am a little confused about what is new about this policy.
I bought an iPad mini late last year. When I set it up to access the NASA Exchange server at the time, the device immediately required me to establish a 4 digit pass code and it set the lock time to 15 minutes. The possibility of disabling the pass code or setting the lockout time to anything greater than 15 minutes were no longer available (either greyed out or missing all together). So, this part of the “new” policy has been implemented at least since late 2012. I wonder what exactly is going to happen on Sep. 10??
Now, I have had a NASA iPhone for about three years, and all of these policies have been enforced on that device since it was delivered from ODIN (a former IT service contractor for NASA). I had noticed that the security settings were part of a “iOS configuration profile” and that from time to time these profiles need to be updated. In fact, you can see some basic information about the “configuration profiles” on the device by looking in the “Settings” app under the “Profile” tab. On the NASA phone, I have two “configuration profiles” that have names with the string “ODIN” in the name. So far this is all pretty straightforward.
So, when I looked at this new CIO memo, I was confused as mentioned above in that I had all the security settings on the iPad activated from the moment I set up access to my NASA Exchange account. So, I went on the iPad to look for similar “configuration profiles” and surprisingly I found that there were no profiles installed on the iPad. I just had to dig into this mystery.
What I found after an hour or so of Internet research and some testing on the iPad is that NASA is using ActiveSync features of MS Exchange to enforce the security settings on my personal iPad. I noticed that I can login to the Outlook Web Application (OWA) and see that I currently have the ability – on my own – to remotely wipe clean either the NASA iPhone or the personal iPad from OWA. I also found that if I disable syncing of Mail, Contacts, Calendars, and Reminders on the Exchange account installed on the personal iPad then I regain the ability to disable the pass code requirement, etc. etc. Mystery solved – at least that one. Answer: On NASA devices the security settings are being enabled with “configuration profiles”, and on the personal iOS (and I assume Android et al.) devices the security settings are being enabled by features in ActiveSync.
But the mystery that remains is what is going to change on September 10? I guess the policy of needing to immediately report a lost or stolen personal mobile device to NASA if it has been connected to Exchange server is new. Also possibly new is the need to not let anyone else use the device as well as all the other expected behaviors in that part of the memo. So, I guess that means someone can’t hand the phone to anyone else during a phone call? Say I am talking to my sister, the policy seems to say that I can’t hand the phone (a personal phone) to my daughter for a minute to talk to her aunt if it has an enabled Exchange account installed!!! And it seems that in order to regain that capability on the phone, NASA expects one to wipe the phone. Doesn’t seem like that this is a big incentive to the whole BYOD idea!!!
So does anyone have the straight dope?!? Does anything change on my iPad come Sep. 10? Are they going to require the installation of a configuration profile as is done for a NASA supplied device? Or is this just formalizing the ActiveSync settings already implemented on the NASA Exchange Server as well as stating the (new?) expected behavior policies (the immediately report to NASA if lost/stolen, do not allow anyone else to use the device, etc. etc.)
Thanks,
Forrest Lumpkin
and the screen lock is still configurable and you can disable at least on Android.
if after Sept 10th you get your 4 digit pin wrong 10x it will wipe your device. not just work email but the whole device.
if you had jailbroken your ipad to install Cydia widgets and other apps you will have violated policy and probably active sync will shutdown.
you will need to get permission and use vpn to access the WLAN.
The policy simply says that all Exchange accounts will have security settings pushed to devices that are configured to connect to their NASA Exchange account through ActiveSync. The settings were already turned on for anyone who had a NASA-issued device, but were not turned on if you did not have a NASA-issued device. The policy says the settings will be turned on for all accounts, regardless of whether the device is NASA-issued or not. At some point in the past, you were issued a NASA device so your account was already enabled to push the settings. When you connected your new iPad to your Exchange account, the settings were pushed.
OK. It makes sense now.
The secure interfaces in the banking industry are for administrators, not users. Users get to manipulate billions with normal https interfaces. There have been a few major incidents but these have usually involved small banks with insecure server software.
Yikes! NASA just shut down the entire webmail interface to email and even people.nasa.gov. What gives???
Come on people. Your employer is offering a perk to use your own device and the complaints start rolling in. If you don’t like the policy, do not bring your own device to work and don’t expect the govt to provide a replacement. Contractors can go to their company for a encrypted laptop , USB drive, and phone then. Feds already get encrypted devices through ACES ( Ugh!)
it is a perk for the manager that we use our own device. saves them IT $, they have 24/7 access to us, if they want to keep that same access now they are going to have to pay. I am looking forward to not feeling obligated to answer that email after hours own my own time just cause I sync work email on my personal device.
No one is obligated to answer email or the telephone outside the normal duty day. Show me the regulation that says that and I will buy you lunch. If you feel that way, maybe you need to step back and re-address you work-life balance and the culture of NASA. Maybe JSC senior leadership needs to re-read the Director’s guidance on Work-Life Balance. My light turns off at 3:30pm every day whether there is work to be done or not. Why? Because the work will be there in the morning waiting for me and I don’t get bonus points for working late.
“Obligated.” I think that’s where you miss the mark. Many, many NASA personnel are _motivated_ to work outside the hours for which they are paid, and indeed the Agency would never have achieved what it has in the past if “work to rule” were the prevailing attitude. Many engineers, technicians, and scientists identify more with their job activities than as what they do 8 x 5, and in many cases, budget cuts mean the default is “on call” in the operational world.
Perhaps the prevailing attitude at Headquarters or HEOMD is different, but I really, really doubt it.
I want people to be happy with their work and work where ever, how ever, with whatever and whenever they want. Frankly I think the whole time card thing is so last century, but good luck changing to something different.
Government as an ‘entity’ is all about measuring stuff, not so much about getting things done. That’s the CYA attitude.
Government as ‘individuals’ is fed up with useless make-work to satisfy checkboxes that don’t matter.
Our engineers are the best in the world because they want to get things done, they love their work, and despise useless measurement stuff for reporting purposes. I do to. I came from DoD after 15 years partly because I was fed up with that kind of chain of command thinking. I understand why they need it; I just didn’t want to be a part of that anymore. NASA is an awesome Agency to work for; we do things no one else does; we do more disparate things than anyone in the world.
I don’t think there is ‘a’ prevailing attitude at HQ or anywhere else — there are just many differing views on what and how to do things, and what looks like a prevailing view is really an official stance that picks one or more of the competing philosophies of what we should do and advertises that as what ‘NASA’ wants to do.
It is your device; it was your choice to connect to NASA email servers with it. Nobody forced you to do it. I don’t know who your manager is, but take some responsibility. If you really felt obligated to answer work emails 24/7 on your own personal device, sounds like you should have deleted the NASA Exchange config from your device a long time ago. If you felt obligated to use your personal device to do so, we’ve now done you a favor and given you a reason to not be responsive to your manager 24/7.
If your attitude is typical of NASA IT people then you should not be surprised that NASA employees simply do not trust NASA IT people. “We’ve done you a favor” Wow.
I meant it – this NASA employee feels like he has to respond to his manager 24/7. I don’t think that’s right, and now he has a reason to not do so.
Here’s what I sent out to people in our directorate on Tuesday to help clarify the policy. Maybe it will help you get your facts straight. And I accept your apology, in advance, for questioning my attitude.
============
NASA will be implementing the IT security measures described in the attached memo this week. I am sending this note to all of HEOMD so that you have a clearer understanding of what this means to you and any personal devices you connect to NASA’s email / NOMAD ActiveSync service, and so you aren’t taken by surprise if or when your personal device starts asking you to do things, like setting an unlock code.
– ActiveSync is the primary means of connecting a device such as an iPhone, iPad, Android or other type of device to NOMAD so that you can access your NASA email on the device. ActiveSync has the ability to ‘push’ certain policies to any device that uses ActiveSync to connect to NASA’s email system. When you configure and connect your device to NASA’s email system, though you may select “Microsoft Exchange” as the connectivity option, ActiveSync is the actual service and protocol that does the work to create and maintain the connection and to get and send your email.
– Understand that NASA has not banned use of your own personal devices to access NOMAD / NASA email, though NASA does have the authority and ability to do so. The phrase “Bring Your Own Device”, or “BYOD” is used to denote such devices that are not issued by NASA or the Government, but which are instead personally owned.
– For some odd reason, there are a significant number of non-NASA issued and non-Government devices that are accessing NOMAD via ActiveSync. Even more odd is that the number of new non-NASA devices that connect to NOMAD increases significantly in the days and weeks immediately after Christmas. (Yeah, I know why, but I want to add a sense of mystery here).
– Accessing email and other NASA information that is not for public release via personal devices does pose some risk to NASA data; implementing certain security precautions on a device helps reduce that risk significantly should that device be lost or stolen, regardless of whether it is a government-owned or personally owned device. Connecting to NOMAD via a personal device is a privilege, not a right. With the privilege come some restrictions, and some risks. By connecting your personal device to NOMAD or the NASA internal network, you are implicitly accepting those restrictions and risks.
– The attached policy is a compromise between allowing use of personal devices and banning personal devices entirely from connecting to NOMAD. The goal here is to ensure that some minimum security is enabled on any device that NASA does not manage and that is connecting to NOMAD.
– The policies that NASA’s NOMAD / ActiveSync server will be pushing to your personal device at a minimum will enable several capabilities on your device to improve its security. First, the policies will ensure that a PIN or passcode is set and that must be used to unlock the device so that if it is lost or stolen, it will not be easy for an unauthorized individual to gain access to your email. Second, where a device can implement this, the policies pushed will set the device to be auto-wiped if there are more than 10 failed attempts to unlock the device; this is to reduce the likelihood of a brute-force guessing of the unlock code. Third, the policies will ensure that encryption capabilities for data-at-rest are turned on for your personal device.
– Each device is different, so I’m not certain what the effects will be on every type of device. I do know that for iOS devices such as iPhones or iPads the changes won’t be too onerous. iOS uses data-at-rest encryption by default, so that is already turned on. If you do not have an unlock code set on your iOS device, once the policies are pushed, you will be prompted to set at minimum a 4 digit unlock code, and your device will auto-lock after 15 minutes being idle. Also, failure to input the correct unlock code after 10 tries will auto-wipe the device. Also, the option is there for a remote wipe of your device from ActiveSync, but that option will not be used without the device owner’s direct permission and by their request. Again, I am not certain what you will see or how other devices will react to the policies being pushed.
– Contrary to the nonsense you’ve been reading at nasawatch or elsewhere, NASA does not obtain control of your personal device; NASA cannot remotely read the contents of your device; NASA does not know your unlock code; and NASA will not remotely trigger a wipe of your personal device without your direct authorization to do so. We are NASA, not NSA. Don’t drop the first ‘A’, eh?
– Please be sure to back up your device regularly through whatever mechanism is available to you based on your device’s capabilities. This protects your configuration and your data should you lose your device or should it be wiped because someone else attempted to unlock your device (you should probably explain to your kids or other family members that they should not attempt to guess the unlock code), or because you requested that NASA remotely wipe your device for some reason. It is also possible for mistakes to happen; there is some risk that your device could be remotely wiped by accident, though that risk, I think, is very small. That is one of the risks you are accepting by connecting your personal device to NASA’s email system.
– If you do not like or agree with any of the changes being pushed by NOMAD / ActiveSync, you should not configure your personal device to connect to NASA’s email system; if you are already connecting to NASA email with your personal device and you don’t agree with these changes being pushed, you should delete your NASA email account from your personal device immediately so that these policies are not pushed to your personal device. If the changes have already been pushed to your device, you may still delete your access to NASA email from the device, and then manually remove whatever policies and restrictions were placed on the device by ActiveSync.
– No one wants their personal property tampered with — we understand that. If you complain loudly because your device does something you don’t like as a result of the policies and settings pushed to your personal device as a result of our efforts to improve IT security, or if mistakes are made and you happen to be the unlucky victim of one, and it gets enough attention, either personal devices may be banned in the future from connecting to NASA email and non-public facing systems, or you’ll have to officially request the ability to connect a personal device, take SATERN training, sign paperwork explicitly accepting the risks to your personal device or data, and so on. That will add more bureaucracy and obstacles and hassles to doing what should be a reasonable thing, which is enabling you to read and respond to email via your personal devices. It’s up to you how you respond to these changes. If you don’t want NASA making any changes to your personal devices, please do not connect your personal device(s) to NASA email or internal networks. This is a compromise that allows your flexibility and choice. And please note that these changes will help protect your personal data on the device, not just NASA data.
I hope this message has allayed any fears or concerns regarding these changes. Understand that without these changes it is likely that, at some point, NASA would have to ban the use of all personal devices entirely. If anyone has questions or concerns not addressed here, or if I’ve not been clear or have made a mistake anywhere in this message, feel free to send me a note and I’ll get back with you as soon as I can.
Thank you,
/s.
Scott Goodwin
Chief Technology Officer
Human Exploration and Operations Mission Directorate
National Aeronautics and Space Administration
Washington, DC
And today, yet another reason not to use a NASA (contractor)-provisioned phone:
http://money.cnn.com/2013/0… .