While trying to get management and other users to buy into learning Dynamo, one topic keeps coming up that keeps frightening them away:
What is the risk of downloading malicious code from the dynamo package manager or other locations “that’ll infect our machines/network” or “upload our data to a 3rd party”
I know sounds silly, but they do fear that a user would download a innocent looking package that’ll actually upload the model to a ftp site in the background while say … exporting room data to an excel file.
Any advice?
I agree with @Konrad_K_Sobon on this, but i have the following to add.
With dynamo being open sourced anyone could check the code from that point of view as a vetting process, then as long as the packages are not done in c# you could vet them in a off the grid system/virtual machine arrangement.
The only areas that i would worry about if i was worried would be the python coded nodes and c# coded packages, as these will be the only two vector points that would be used.
To vet a python node you can open/read/understand the code prior to running by checking what modules are imported and what the code does.
A lot of the time benefits of using dynamo would be lost because of the extra time required to vet all of the packages at every release.
Konrad - your response is a little irresponsible imo.
Are you telling us that there is no chance someone will create a malicious python node?
Are you telling us that no one would want to steal a dynamo model of any building?
There are numerous accounts of people writing malicious code, “just for a laugh”.
Most dynamo users won’t be programmers so their concerns are real.
What is to stop someone writing a malicious python node? How can a ‘regular’ user vet this?
Talking to those that have raised these concerns have come from a background of having working in certain fields like nuclear, where security is pretty tight over the model data - computers on lock down, no paper left on a desk when your not at it…
Thanks to those that taken the time to respond. Was informative.
I thnk one of the best answers was from @Yna_Db. Simply put, use packages that are well known and created by people who really want to hurt their reputation.
This includes (but is not limited to) the list on the primer.
It seems that the 430million malware created in 2015 paints a different picture than that they just wanted to do it for fun. Also there is more to this than something looking like something for you to download, there are usb’s that can make a computer think it is a keyboard so it will accept the inputs from it.
There is generally two areas that malware is created for, to get to your data or control your computer to do other task with.
These can then give that person the ability to generate money from your identity by either getting money from your bank/ordering things in your name/using your info to gain access to websites you are on(amazon/paypal/etc)/sell this infomation on to other parties.
Steal your companies intellectual property.
From a government point of view this could be espionage.
Use your pc as part of a attack(botnet) on a company/government organisation/etc.
Its not so much a Dynamo issue at this point, as it is an issue of Admin versus User permissions, and what does the IT department allow folks to do on the company machines.
While it may seem limiting and hamstringing, i dont think its outlandish for IT groups to consider installing Dynamo in a controlled fashion, meaning: Users cant update their builds, and users cant install packages on their own. Obviously companies need a mechanism for testing packages in a controlled (but fast) environment, before shoving them out to all users, but yes: its a very real concern.
Dropbox and Box have both led to real companies getting cryptolocked out of their own files, for periods of time. Email, P2P file transfers, etc. They are all things company IT groups need to deal with.
Ive been talking with Gordon Price a LOT about deploying Dynamo, and managing it at an enterprise level, as that was/is my hesitation to want to get in to Dynamo. If we dont have a way we recommend companies deal with it, eventually they will just shut the door on it. Companies serious about security already do that to other apps they cant vet and protect inside.
This discussion is becoming really serious and should maybe be reported on another level. I would assume, however, that a cost analysis should be done to compare productivity gains with the cost of a Code Security Analysis or something similar?
Oh wow. I haven’t heard that tone on this forum since … never actually. @LARCH - since you’re obviously a new member you may not have taken the time yet to review our community guidelines. I would suggest you do that at your earliest convenience. The Dynamo community is by far the friendliest community I have been involved in so far and we would very much like to keep it that way. Please refrain from calling other peoples’ opinions “unqualified” in the future - there are more respectful ways of voicing your disagreement.
@lordsummerisle - I would agree with @Konrad_K_Sobon and @Brendan_Cassidy and add the following (elaborating a bit on what @Yna_Db wrote) :
At least in the case of Python-based nodes it could be assumed that the vetting is performed by the community. Lots of people on this forum regularly take a look under the hood of a lot of the Dynamo packages out there. So I think it’s fairly safe to assume if a package has a certain number of downloads under the belt and nobody here has complained about it being malicious that it will be safe to use. In fact, I would actually consider it safer than downloading a Revit addin since that is actually closed source and may be logging my every key stroke for all I know.
I think what we need to be concerned about is something else. As @Aaron_Maller has pointed out, we need more control over what users can do with Dynamo. Because they are the single greatest risk in cyber security. Gaining control over who can use the package manager would be a good start, I think:
The ability to disable Package Manager for some users
The ability to tie other users to one users Package Manager (so a BIM Manager installs, everyone gets package).
Right now, i do number two with a series of Robocopies, and it works like a champ. But, the ability for someone to update a package (one of you gifted folks that develop packages), and for a BIM Manager of 1000 people to test it in a controlled setting, and then “push” it to all users on prem?
Silly as it sounds, Dynamo would get ten times more powerful than it is now.
Aaron-
I too wish we could disable the package manager for everyone except the trusted few.
For your #2 - I would not recommend that the BIM Manager’s installs be pushed to everyone. The BIM Manager is likely the tester/gatekeeper - he will install and vet things, then the good stuff would be pushed out to all using the a common networked library of packages (via Settings/Manage Node and Package paths) that the BIM Manager controls the contents of. Copying everything he/she has would defeat the purpose of protecting the majority of users wouldn’t it?
@Ben_Osborne beat me to it.
We have all our packages located on a read-only network drive and Dynamo gets deployed with a customized DynamoSettings.XML that points the packages path to that drive. When I want to push out an updated package I simply put it on the network drive.
i’m guessing what @Aaron_Maller was meaning was a BIM manager could maintain a folder from which all office users get the authorised packages.
i’m thinking as a workflow - Dynamo manager downloads a package to their local machine, once vetted - copy package to second folder - robocopy this to a networked folder location to which all office users have their dynamo pointing too.
One hacky way to disable the package manager is to deploy a customised DynamoPackage.dll.config file to all users, without a packageManagerAddress value. Once its removed, it will no longer be able to find the server…and so no user will be able to download anything:
The issue with security was a concern of ours for all of three seconds. The benefits far outweigh the risk by an exponential factor.
Typical digital security will block or severly limit 99% of the issues they are worrying about. For those aspects Dynamo is no less secure than the rest of the stuff you use. The small remaining portion of issues are exploits so rooted deep in the system that no one would waste leaking them to the world via dynamo. Be it for fun or profit, they will be exponentially more successful in getting the malicious code into the system via other means.
Note that the package manager website (https://dynamopackages.com) shows less than a half million downloads so far. That’s a great number that many of the people reading this post should take a TON of pride in by the way. Thanks for all you guys do. Someday I hope I can be 1/10 as helpful to the community as the publishers have been to me. Thanks.
By contrast a well placed and distributed bit of code that works with something like the heartbleed exploit (Heartbleed - Wikipedia) can hit that many systems in a nano second. Interesting to note that autodesk software you likely use was impacted by this but the fix wasn’t out for 23 days. How did the bosses handle that? Most of the industry didn’t care and continued with business as usual. Keep in mind similar exploits and malicious code could be hidden in manufacturer PDFs and DWGs, RevitCity families, or even a web ad placed through Google. The only way to be 100% safe is to never bring any outside data into your office.
Is it possible that malicious code could be snuck into your systems via dynamo? Yes. Its also possible for a disgruntled employee to write a .bat file that turns your exchange server into a brick. Fortunately, neither are very likely and I won’t be losing any sleep over them. It’s far more likely (boardering on certain) malicious code has already snuck into your system via the numerous other items you use daily, or that you have a far larger exploit ready for someone to crack open. We just don’t know about it yet.
Don’t let the fear of ‘what if’ deny the firm the benefits the rest of us are seeing. Instead take an opportunity to review your company security protocols (I.E. no user should have complete system access) to limit exposure. I reccomend using an external vendor for this who can help you look at things with fresh eyes. You will be safer long term against the very unlikely dynamo attack (or bat file wielding employee) and the absolute certainty of a large distribution attack.
