Cool Solutions

securing designer projects



By:

November 27, 2006 11:25 am

Reads:3,110

Comments:8

Score:Unrated

security As we extend designer’s offline capabilities, people will be storing more and more sensitive data in their designer projects. Many consultants are taking their customer’s data – stored in designer projects – out of the protected networks and buildings. Business logic, processes, passwords, IP addresses, administrator phone numbers, email addresses and more. how is designer going to protect your and your customer’s data?We are investigating for our Designer 2.1 release how we can better protect sensitive information in Designer projects. Sensitive information is not only passwords but also business logic and address and contact information that you may have stored in Designer. So far on our list of data that needs enhanced protection are:

  • Passwords
  • IP addresses
  • Contact information
  • Password protect a complete project

In your mind, what other information do we need to (better) protect in order to serve you best?

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading ... Loading ...

Categories: Uncategorized

Disclaimer: This content is not supported by Novell. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.

8 Comments

  1. By:Mr. Anderson

    Volker,

    Great topic, but what are your plans? Are you thinking about encryption of entire projects? How about server-side-only projects (not being able to download the project offline anymore,..)? Encryption of driver and driver-set exports?

    Hmm, thinking about the server-side-only option,.. As you mention customers do not want their data out of the office, so a boolean on the driver-set, stating that the data can only be edited on the server side, not imported in the designer workspace, could be a fancy one. That would make designer a next generation local iManager,.. But it would solve your problem. The only thing with that, or maybe any other solution, somebody has to set that boolean value… And what can be set can be unset as well.

  2. Mr. Anderson,

    we are not planning on cutting down Designers revolutionary off line capabilities. We firmly believe that the data can be protected in a way that it doesn’t matters if it leaves the corporate network or office building.
    I know that some financial institutions in Switzerland require external Consultants to use an encrypted file system to store project data. But even these institution acknoledge and respect the need for off line work as it dramatically reduces expenses on both sides.
    So our plans are to better protect the data but we don’t want to open a can of worms by just encrypting everything. If we were going to encrypt all project files, for example, we could not use a file-based version control system anymore as they operate only on text files and don’t work well with binary files. So if we encrypt only partially, we need to know that exactly our customers need to be encrypted.

  3. It would seem that most software companies do not see it as their responsibility to protect the data within applications. I am happy to see that some thought is going into this. As a short term solution SLED 10 already provides a really acceptable answer. We just encrypt the entire /home partition of a system. When it is unlocked and in use revision control software works great. When it is locked and not in use it is a brick. That way when you store and save any data not just project data you do not leave it unprotected.

    The second part of the application protection side should still be done though. It would make the most sense not to reinvent the wheel and use an already acceptable form of encryption that has been tested and verified. The worst problems arise when people try to build “custom” encryption algorithms. It would seem that using a public/private key would be best. Something that allows the private key to be password protected to unlock the files and something that would allow it to be stored outside of the computer system. It should also be transparent so when encrypted files are accessed by other utilities like svn it would still work as a text file read not a binary read. Something related to the eCryptfs (http://ecryptfs.sourceforge.net/) may be worth while. It has transparent access and works well to protect files transparently. It also made it into the latest Linux kernel. There are many ways that are acceptable though to solve this issue.

  4. Adam,

    this is a great comment, thank you. We will ivestigate the options that you listed. I totally agree (and so does the whole team) that we will not be re-inventing the wheel when it comes to encryption but use proven and mature technology. Public and private key cryptography was our preferred choice until now and so far nothing better came across.

    We won’t tie ourselves to an OS-dependent encryption solution, though. We want it to be encapsulated into Designer and under our full control. One thought on your recommendation of Cryptfs and transparent access:
    I’m not sure this is what we really want. Consider the following situation: You have highly sensitive information like passwords, IP addresses and certain business logic in your project. You are working for a financial organization and thus you decided to encrypt sensitive information by specifying this in the Designer preferences. Your customer wants you to check-in your project into the exsting subversion system. Now, if you check-in the files in clear-text (because of the transparent access provided by Cryptfs) your security ends right there. Everyone hacking the CVS server or gaining legally access to it would see your private data in clear text.
    So our idea is to always leave encrypted data encrypted (if possible) and hold up protection even if the project get’s checked-in into a version control system.

  5. I completely agree about the check-in system in regards to passwords and such. But if you encrypt everything in what is supposed to be a collaborative environment (svn, cvs) you end up with running a key escrow system so everyone can access the information. I am not sure anyone wants that. Sounds like you guys are moving in a great direction though. It is really good to see this type of thought make it into product.

  6. You think it is not a good idea to have every project member know the project password(s)? Please tell me more about the “key escrow system” so that we understand what we don’t want to build.

  7. Key Escrow is putting in keys that can be deciphered or read by an admin or another user to access “protected” or “encrypted” data. There are several places where Novell uses similar technologies today (for mostly good reasons). The basics idea is to setup a key (encryption) that the user uses to encrypt the data. Then allow the admin to be able to unencrypt it for valid or invalid purposes. The problem is that when a system is introduced that can reverse engineer the encryption it becomes difficult to justify using the encryption in the first place. It also becomes impossible to provide reasonable security. The only area where that type of technology is used today is when dealing with Password Sync. It is a difficult subject though. for password sync you have to provide those functions or things like IDM would not operate and password sync would not be possible. So I guess what I am saying is, for data protection schemes it is better to say that if a backup of the key is lost the data is lost also. Backdoors or static keys are often a bad idea. There are other issues with static keys and backdoors in encryption schemes. It does not provide sufficient auditing when it comes time to show the AAA were followed. It is not possible to make the statement that no one else viewed the data when encryption can be reversed by several people (it at least makes it much more difficult).

    Sorry to ramble. This may be better to take offline in the long run. It also may be worth while to look at things like fips140 standards when it comes time to implement this type of a system.

  8. By:Mr. Anderson

    Thanks for the explanation, it remains an interesting topic, looking forward to see what will come up.

Comment

RSS