Skip to main content

R&D has decided to drop support for external document  repositories which has been core capabilities for at least 20 years. 

See link

https://community.ifs.com/topic/show?tid=39710&fid=248

This functionality is critical in a number of ways as it enables the following use cases.  This will affect any customers that serve A&D, Utilities, and other industries where they have a need to have elevated security for some documents.  This will also negatively impact customers that have multiple legal entities that have implemented separate repositories to keep their physical documents separated.  In addition this will affect any customer that has multi country country requirements to store data locally.

Overall this will also affect the marketability of the IFS hosted cloud to both existing and new customers.

Below are some use cases

 

Use case 1:  Customer manufactures dual use products and technologies and sells to both  commercial and defense markets. They have some ITAR requirements for some items only, and do not need a full Gov Cloud solution. In this scenario with the capability to have external repositories, we can implement this customer in IFS Cloud, with IFS Cloud hosting and manage any sensitive documents in an external repository, but still have them linked to the appropriate functionality and control their access through security. Their storage in an ITAR controlled repository gives them the coverage they need.

 

Use case 2: electric utility implementing in IFS hosted cloud– by law / regulation power and utility companies cannot store potentially sensitive documents on the cloud. Any documents that may contain any information that could expose any information of vulnerabilities cannot be stored in a cloud.  Having these sensitive documents in an on-prem location, but linked to metadata in IFS Cloud enables them to maintain an extra layer of security.

 

Use case 3: on prem utility provider–  is implemented on prem, but as many of our customers are, they are comprised of multiple legal and operating entities each with their own set of users and documentation.  Because IFS implementation of document management is global, i.e. is not company specific, we implemented multiple repositories and classes for each company  to ensure that we physically kept each companies documents separate. This prevented anyone from being able to gain access to all of the documents even in the event of a breach.

 

Use case 4: Multi-Company, Multi-National customers – in many cases we would want to implement document repositories in the region they are located and or segregated by country/company for performance and security reasons.   i.e.  companies with Israeli locations or entities, and also locations or entities in the middle east.   Or companies with legal entities in France or Canada which have regulations that require data reside in country.

I can see why FTP might have been dropped, but why not replace it with SFTP,. Don't just drop it with no path forward.

 

That said I 100% agree with Dean the ability to set up separate repositories, is key, it allows customers to keep data that needs more advanced security controls in place segregated. This is a MUST for users in Highly Regulated Industries and the existing function was the great solution that allowed us to mange data subject Export Control and Sovergity Regulations in DOCMAN.

Thanks @AlexSharp for joining in.

Can you elaborate on this:

it allows customers to keep data that needs more advanced security controls in place segregated.

What does “segregated” mean, practically? What are examples of advanced security controls that differs from the ones we have in Docman? The more details we can get, the better we can understand the needs and how we can fulfill them.

I personally don't see that you can get "real" export control using even the existing feature. It's "false security", if you ask me. And, as stated in the other thread, our customer SAAB does not think what we have now is good enough.

And, again, we are not removing the option of keeping documents outside the database, but it will initially be limited to one physical location (one network share).

 

We also use multiple document repositories tied to the document classes to store files outside of the database and I feel this change is something that would cause us great pain. That being said, I would like more clarification from @Mathias Dahl on the “one physical location”. Currently, we point each class to a folder based on the company/department it is associated with, but these are separate folders beneath a single Windows share. We did this for several reasons.

1.) Fear of the database growing rapidly and creating performance issues

2.) Flexibility to manage retention of documents as we see fit (not bound by database rules)

3.) Ability to further separate these repositories, based on company growth and evolution

Point 3 gives me pause to reflect on how this might be impacted by the “one network share” aspect of this new direction IFS is taking. I totally support the growth and evolution of the product as we all know the vulnerabilities of simple ftp (sftp makes much more sense for the security conscious organizations eg. @AlexSharp)  and the pitfalls of storing large documents inside of the database, but to just “pull the rug out from under” existing customers shows a certain hubris (or at the least, short-sightedness) on the part of IFS. While this in and of itself might not be a reason for us to steer away from IFS Cloud, it certainly becomes a pain point that might open the door for us to consider an alternative document management solution, which was one of the main features we wanted when we chose IFS in the first place.

 

Thank you @DeanBurell for the opportunity share in your “idea” regarding this proposed change and thank you @Mathias Dahl for your participation in this discussion.

 

Regards,

RHOWE

@Mathias Dahl   In response to your question segregated;  for me this is the use of different physical file shares (which normally is also separate physical hardware). I have seen that approach in several defence business when they wan to keep ITAR and CUI data way from the rest of the enterprise data, and it has never given them compliance issues. 

I have also seen data stored on separate networks and IP based restrictions put in place. This approach does force the use of static IPs (in some cases) which generally be a pain to manage, but in some cases its needed because of the level of classification of the data.

@Mathias Dahl   In response to your question segregated;  for me this is the use of different physical file shares (which normally is also separate physical hardware). I have seen that approach in several defence business when they wan to keep ITAR and CUI data way from the rest of the enterprise data, and it has never given them compliance issues. 

I have also seen data stored on separate networks and IP based restrictions put in place. This approach does force the use of static IPs (in some cases) which generally be a pain to manage, but in some cases its needed because of the level of classification of the data.

Thanks @AlexSharp 

We can understand the need, on some level.

What we don't understand is the need for segregating the electronic document files *at the same time* as it's accepted to keep all the business/transaction/basic data inside the same database, where it's not segregated in any "physical" way. It does not make any sense to accept one database but require multiple file storage locations.

Unless, that is, it's *only* the document file content that's subject to export control, and no data whatsoever in the database. That sounds unlikely since it means that the IFS database contains no data/information that is subject for export control.

Can you follow our reasoning? Is it flawed?

PS. If it helps, why not see the file storage as being an extension of the database? It's not a separate thing, logically. In the same way that Oracle might store data on separate disk drives in separate database files.

 

Reply


Terms & ConditionsCookie settings