Security has become the number one concern of just about every IT department around the globe. And if it is not a concern, it surely should be. We typically do not consider Agile environments to be at risk since they usually reside within the corporate environment or behind a secure proxy server if exposed to the public internet. However, some estimate internal attacks to be as high as 65% of all attacks and even the optimistic statistics measure it at a fifty-fifty chance the attack originated from inside the network. Whichever number you choose to believe, it is apparent that we should be protecting internal assets with the same vigor we protect our external facing assets.

Agile User Security Model

As with all other IT systems, the overall security begins with the end user. Enterprises are becoming increasingly globalized with sensitive information and data being shared across multiple locations. With regard to your Agile PLM system, you should consider implementing an access control model that drives compliance to standards such as International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR). This access control should be built around the user criteria, privileges, privilege masks, and roles used within the system.

Principal of Least Privileges

Another security rule to remember when administering an Agile system is to limit user access to only those functions and data types that are required by users to properly perform their work. This is referred to as the Principal of Least Privileges. Undisciplined use of groups/functional teams, roles and global permissions can open a system to abuse of the security model including access to unauthorized data. This is especially true of the Administrator privileges and their assignment. A security best practice would be to forgo the use of the built-in ‘admin’ account for administrative purposes and create specific user administrator accounts that differ from the user’s normal account. This has the effect of separating administrative tasks from normal work, providing a detailed audit history and preventing the accidental use of administrator privileges during a session. This is even more important when using external (i.e. LDAP) authentication methodologies. In these cases, we would recommend creating separate administrator accounts for admin users that are internal (not LDAP) accounts. This will provide an additional layer of access should there be an issue with the external LDAP connection.

Session Timeouts

One of the most underused security tools in the Agile PLM system is the session timeout parameter. The parameter is typically set very high (6 to 8 hours) to make the system more convenient for its users. However, this opens the user sessions to possible hijacking when the user leaves the work station for even brief moment. Consider this tradeoff of convenience and security carefully.

Agile User Account Maintenance

Agile PLM user accounts which are stored in the Oracle database (as contrasted with LDAP based authentication systems) require on-going management. Account passwords should have a reasonable expiration timer that will force users to change their passwords on a regular basis.

Agile offers a full set of Account Policy settings that can be used to increase the security of database user accounts. The process includes password age, length, uniqueness and password rules to be applied to all users. Prudent use of these settings (available in the Agile Java Client) will greatly enhance the security of your user accounts.

Additionally, administrators must be vigilant in disabling unused accounts as these can easily become a source of unauthorized system access. Agile has a full compliment of Administrator reports to help track and manage inactive Users and Functional Teams. Regular use of these reports can help the Administrator to properly manage access and changes to the security model.

Internal and External Authentication

Agile provides a full featured internally managed user account system based in the Agile PLM database. Agile will also integrate with external corporate wide systems such as Active Directory. Each scenario provides its own advantages and challenges.

Using external authentication services (generically termed LDAP) for Agile users is an excellent way to integrate Agile security with the corporate security model as accounts will transparently be subject to the security controls and demands of the associated system such as Active Directory. However, this integration does not remove the need for user management by the Agile PLM administrator. Accounts still need to have appropriate roles and privileges assigned and accounts removed/disabled when necessary. It also places an extra burden on the Active Directory management team in that they must make careful use of group assignments to ensure that only authorized staff accounts are included in the Agile ecosystem and that these accounts are removed from the associated group(s) when no longer needed. Unfortunately we have seen too many Active Directory systems where terminated employees are not removed from the system (promptly or at all) and this creates another avenue for attack of the Agile system.

Software Updates

Software Updates are generally considered by security professionals to be one of the key elements of maintaining system security. Keep abreast of current versions, security bulletins and important hot fixes by regularly checking MyOracle Support.

Be sure to monitor your Agile PLM system and regularly review audit records to help ensure it is performing as expected and that the expected tasks are being performed by the expected user base.

It is also important to keep the underlying operating system up-to-date to prevent the exploitation of vulnerabilities.

Default Passwords

We have worked on a number of production systems which use the default password for the database connection. This is the equivalent of handing someone the master key to your building. By using the default Oracle database login, a ‘bad actor’ can steal your data and easily make your system unusable at the same time. Make no mistake, the default password of ‘tartan’ is well known. The process of changing the database password used by an Agile system is well documented by Oracle in the Knowledge Base as “Steps Need to Be Taken in Agile Application Server After Changing Agile Database User Password From 9.3.2 and After (Doc ID 1997984.1)”.

Needless to say, it is easier to use a different password during installation than to change it later. Be absolutely sure you document (in a safe place) ALL of the Agile system passwords including the database password.

SSL and Encryption

Agile systems can be configured to use SSL, also known as HTTPS, encryption on the servers or via a web proxy/load balancer. If you have any doubts about the security of your network then you should consider configuring SSL for your environment. However, for a true implementation you will need to obtain SSL certificates issued by a Certificate Authority. The expense involved in obtaining and maintaining these certifications should be carefully considered when deciding on SSL encryption. It is possible to configure Agile SSL using self-signed certificates but the result is a more cumbersome user experience.

Summary

Creating and maintaining a secure Agile PLM environment is not markedly different from securing any application system. However, Agile administration is often split between multiple staff functions with no clear definition of security responsibilities. Responsibilities for ensuring the security of your Agile implementation should be clearly defined and reviewed regularly.

Taking the time to consider these basic principles of secure computing will move you well along the road to providing secure Agile services to your environment.

This post is a joint article written by our IT Director Bob McDuffee and PLM Program Manager Cletus Udoye.