Secure DevOps for PLM

The Bilbo Baggins Threat to PLM Assets

There are a lot of secrets in this world, but not too many can compete with engineering know-how in terms of a strategic impact. In the 21st century that precious know-how is being stored in PLM systems and their digital twin siblings. CAD designs, material information, tooling – all these shiny pieces for Bilbo Baggings’s next adventure are sitting in your company’s 3DExperienceTeamCenterWindchill or smaller/legacy vendors applications.

Modern security breaches generally occur through the following principal routes:

  • Application-level attacks like code injections or brute force based on software bugs/limitations.
  • Stealing data from inside the firewall, which includes manipulating “good” authorized users into divulging their credentials by “social engineering” attacks; acquiring “bad” users via insider threat path; acquiring read-only database credentials (which are often left unchanged for years); or acquiring database credentials baked into other programs.
  • Meltdown/Spectre type of attacks, manipulating the low-level functionality of network cards, CPUs or other physical hardware.

Major PLM vendors focus on the application layer (and they seem to be doing it well enough) for both on-premise and public cloud deployments. They leave defense against the human element, as well as environment and infrastructure attacks, to the relevant implementation, maintenance and security/intelligence teams.

Going after humans provides attackers with an access to whatever is allowed to those humans’ accounts. Application users usually have a rather restricted route to PLM data, while elevated-access IT personnel have direct access to database and files.

PLM systems store engineering data in the database and physical files. It is much more rewarding to steal massive amounts of data by going directly for the juicy, tasty raw databases and files rather than trying to get around the application security setup.

All major PLM vendors are using relational databases such as Oracle and MS SQL to store metadata. A PLM system business logic “unites” metadata using SQL queries. That logic may be reproduced by an attacker who obtains a particular database account credentials and/or steals the entire database, and then runs these queries.

Where does one start defending against such nightmare scenarios?

Oracle’s Advanced Security offering includes Virtual Private Database (VPD) and Fine-Grained Access Control as principal ingredients, and Transparent Data Encryption (TDE) for a comprehensive encryption-at-rest flavor; Microsoft’s SQL Server, while being late to the game, has also developed similar features.

The main idea of VPD is that based on a certain programmable logic, “a predicate or “where” clause is automatically and transparently appended to incoming SQL statements, restricting access to rows and columns within the table.” That logic may be linked to various “contexts” describing a particular user’s account and working environment specifics. 

A so-called database-level trigger fires for any attempt to log into the database. That trigger ensures that user context is correctly applied, and that the entire chain of security policies and SQL predicates is being enforced. Thus, attackers who obtained a database user’s account credentials will be restricted from seeing/changing any data outside of that user’s permissions bubble – because they cannot circumvent SQL-appending mechanism.

At the next level, Transparent Data Encryption assures that even if the entire database is stolen, data there cannot be accessed. That is because the TDE master encryption key is stored in an external security module that is outside of the database and accessible only to a user who was granted the appropriate privileges on the host network.

The only downside of the above is the cost, which only larger companies can afford. SMBs should most probably rely on simpler options, focusing on denying the human element route. Fortunately, there are already offerings in that domain, for example those relying on authentication with hardware-based smart keys, and software products like Ethopass and Proofpoint ITM.

As for files stored in PLM vaults, it is both much simpler and more complicated. One cannot prevent authorized users from accessing these files. The only thing one can do is to make it harder, more cumbersome to access them. However, in the end, if someone decides to put enough effort into circumventing your human element defense, they will often succeed.

Last but not least, sophisticated hardware-level attacks is a relatively new and dangerous path. This is an infrastructure-level issue of biblical proportions, and most if not all relevant vendors and IT departments are so scared that they are disabling all features that make Meltdown/Spectre type of attacks possible – sometimes with an extreme impact on performance.

The moral of this entire treatise is a call to action for PLM corporate users: do not be complacent, do not wait! Do your own research, communicate with your vendor and/or implementation partner – and talk to Senticore about defeating this hobbit menace.

Protect your data, protect your precious! You wants it, you needs it!