Security Aspects

Support Policy for Security Matters

An RLIA for Windchill deployment may be configured with access to mission-critical ALM and PLM systems within an organization. Sensitive information can be found in the artifacts being related, the existence of a relationship between artifacts, and the passwords used to gain access to the systems the tool is intended to work with. This information is considered private and requires appropriate security precautions that are beyond the scope of the RLIA to ensure malicious users are unable to extract artifact information or passwords.

Precautions taken to minimize the risk of undesirable access to raw artifact data consist of both enabling the tool administrator to encrypt all network traffic via HTTPS and requiring authentication from each user for network access to all information. A secured local system/account upon which RLIA is installed is assumed.

Precautions are also taken to guard against the extraction of plain-text credentials. Passwords are encrypted within the RLIA’s storage repository, reducing the chances of malicious password extraction. Additionally HTTPS based network access further prevents passwords from being compromised. AppScan Source and Web are run against RLIA each build and all vulnerabilities are reported and triaged accordingly.

Although every precaution is taken to reduce the risk of security threats that succeed in their goals, such risks can happen as those attempting them modify their tactics. In the event a new security vulnerability is discovered, the RLIA vendor and support agency will notify affected customers regarding the vulnerability. These agents will undertake customary practical effort to diagnose and resolve each such security vulnerability and provide enhanced versions of the RLIA on or before the deadlines in the established Service Level Agreements.


This discussion of security aspects within the Rational Lifecycle Integration Adapter for the PTC Windchill product focuses on the classical CIA triad of security concerns: Confidentiality, Integrity, and Availability.


Confidentiality refers to preventing the disclosure of information to unauthorized individuals or systems.


Integrity means maintaining and assuring the accuracy and consistency of data over its entire life-cycle.


Information must be available when it is needed. This means that the computing systems used to store and process the information, the security controls used to protect it, and the communication channels used to access it must be functioning correctly.

The Process of Threat Modeling

Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables one to identify, quantify, and address the security risks associated with an application. The inclusion of threat modeling in the software development lifecycle can help an organization ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modeling process, can give a reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point. Modern threat modeling looks at a system from a potential attacker’s perspective, as opposed to a defender’s viewpoint.

The threat modeling process for the Rational Lifecycle Integration Adapter consists of three high level steps:

The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves creating use-cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets i.e. items/areas that the attacker would be interested in, and identifying trust levels which represent the access rights that the application will grant to external entities. This information is documented in the Threat Model document.

Critical to the identification of threats is the use of a threat categorization methodology. A threat categorization such as STRIDE can be used, or the Application Security Frame (ASF) that defines threat categories such as Auditing & Logging, Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, Exception Management. The goal of the threat categorization is to help identify threats both from the attacker (STRIDE) and the defensive perspective (ASF). These threats can be identified further as the roots for threat trees; there is one tree for each threat goal. From the defensive perspective, ASF categorization helps to identify the threats as weaknesses of security controls for such threats. Common threat-lists with examples can help in the identification of such threats. Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. The determination of the security risk for each threat can be determined using a value-based risk model such as DREAD or a less subjective qualitative risk model based upon general risk factors (e.g. likelihood and impact).

A lack of protection against a threat might indicate a vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking is assigned to the threats, it is possible to sort threats from the highest to the lowest risk, and prioritize the mitigation effort, such as by responding to such threats by applying the identified countermeasures. The risk mitigation strategy might involve evaluating these threats from the business impact that they pose and reducing the risk. Other options might include taking the risk, assuming the business impact is acceptable because of compensating controls, informing the user of the threat, removing the risk posed by the threat completely, or the least preferable option, that is, to do nothing.

Each of the above steps has been documented as they were carried out. This resulting document is the threat model for the Rational Lifecycle Integration Adapter.

Security Aspects of the OSLC Adapter Architecture

The Adapter is deployed into a corporate network onto a Servlet Engine and as extensions to the already in-situ PTC Windchill system. A typical corporate network with the deployed Adapter might resemble the network shown in the figure.

Typical view of a Corporate Network with PLM, ALM, and Adapter Servers
Figure: A Typical Corporate Network with PLM, ALM, and Adapter Servers. Show image enlarged.

Threat Model of the Domain

The Threat Model herein uses the terminology of several International Organization for Standardization (ISO) security standards--which are provided in the References. The model also exploits the architecture described in the 2006 paper by Caceres and Tehigawara [ Caceres 2006 ].

When identifying and specifying threats, the following questions must be answered:

Figure: Caceres Threat Model identifying the Standard Source of Terms

The figure states the following:

The following figure represents the typical corporate network (with adequate details for discussion purposes yet with simplification of unnecessary detail) with an overlay of the threat actors, entry points, and assets that this threat model describes.

Figure: Typical Corporate Network for PLM and ALM Integration with Threats Shown. Show image enlarged.

Threat Model Information

Threat Model Information
Application Version Description
1.0 The Rational Lifecycle Integration Adapter for the PTC Windchill enables users of PTC’s Product Lifecycle Management PLM Windchill™ ecosystem to share information with IBM’s Automation Lifecycle Management ALM Rational Team Concert™ (RTC) ecosystem. The Adapter uses OASIS OSLC standards, protocols, and user interface elements over modern REST web services to provide this sharing of information. Information is linked between systems, not replicated, optimizing storage and consistency.

External Dependencies

External dependencies are items external to the application upon which the application depends that may pose a threat to the application if those external items do not themselves provide an adequate level of security.

The following query of ExternalDependency individuals from the OSLC Threat Model:

PREFIX rdf: <>
PREFIX owl: <>
PREFIX xsd: <>
PREFIX rdfs: <>
PREFIX threat: <>

SELECT ?title ?identifier ?extTitle ?description
	WHERE { ?threatModel a threat:ThreatModel;
		<> ?title;
		threat:dependsOn ?dependency.
		?dependency a threat:ExternalDependency;
		<> ?extTitle;
		<> ?identifier;
		<> ?description.

		FILTER( str( ?title ) = "RLIA Threat Model" )
	ORDER BY ASC( ?identifier )

Yields these External Dependencies:

Table: External Dependencies

Systems and Asset Access Providers

A particular Threat Model addresses one or more Systems each of which has one or more Asset Access Providers. These Asset Access Providers are the repositories of an Enterprise’s assets. These may be intangible assets in addition to the more evident tangible assets. For example, “corporate goodwill” is an intangible asset provided by the perceived reputation of the enterprise.

The following query reveals the Systems and their Asset Access Providers that the RLIA Threat Model addresses.

PREFIX rdf: <>
PREFIX owl: <>
PREFIX xsd: <>
PREFIX rdfs: <>
PREFIX threat: <>

SELECT ?title ?identifier ?sysTitle ?description ?assetAccessProviderTitle
	WHERE { ?threatModel a threat:ThreatModel;
		<> ?title;
		threat:addresses ?system.
		?system a threat:System;
		<> ?sysTitle;
		<> ?identifier;
		<> ?description;

		threat:integrates ?assetAccessProvider.

		?assetAccessProvider <> ?assetAccessProviderTitle;

		FILTER( str( ?title ) = "RLIA Threat Model" )
	ORDER BY ASC( ?assetAccessProviderTitle )

Yields these Access Providers to Assets of the System:


Systems and Asset Access Providers.

Entry Points

Entry points define the interfaces through which potential attackers can interact with the application or supply it with data. In order for a potential attacker to attack an application, entry points must exist. Entry points in an application can be layered, for example each web page in a web application may contain multiple entry points.

Entry Points have an:

A unique ID assigned to the entry point. This will be used to cross reference the entry point with any threats or vulnerabilities that are identified. In the case of compound entry points, a dotted path notation is employed.
A descriptive name identifying the entry point and its purpose.
A textual description detailing the interaction or processing that occurs at the entry point.
Trust Levels
The level of access required at the entry point is documented here. These are cross referenced with the trusts levels defined in the Threat Model in section Trust Levels.

The following query:


Yields these Entry Points:


Entry Points

Table: Entry Points


The system has information that the agents seek; these items/areas of interest are defined as assets. Assets are threat targets, i.e. they are the reason threats exist. Assets can be both physical assets and abstract assets. For example, an asset of an application might be a list of clients and their personal information; this is a physical asset. An abstract asset might be the reputation of an organization. Assets are documented in the threat model as follows:

A unique ID is assigned to identify each asset. This will be used to cross reference the asset with any threats or vulnerabilities that are identified. In the case of compound assets, a dotted path notation is employed.
A descriptive name that clearly identifies the asset.
A textual description of what the asset is and why it needs to be protected.
Entry Points
The Entry Point interfaces through which potential attackers can interact with the asset or supply it with data is documented here. These are cross referenced with the entry points defined in the Threat Model in section Entry Points.

The knowledge base for the RLIA Threat Model currently stores these Assets:

asset identifier name description entryPoint trustLevel
identityManagementAsset ASSET_001 Asset under the aegis of the Identity Management System Assets related to the Identity Management System authenticationChallengeServiceEntryPoint anonymousWebUserTrust
identityManagementAsset ASSET_001 Asset under the aegis of the Identity Management System Assets related to the Identity Management System identityManagerHomePageEntryPoint
plmAsset ASSET_201 Asset under the aegis of the PLM System Assets related to the PLM System plmProductAreaHomePageEntryPoint plmUserTrust
almAsset ASSET_101 Assets under the aegis of the ALM System Assets related to the ALM System httpsPortForAlmEntryPoint almUserTrust
localhostOsOwnedFilesAsset ASSET_501 Localhost OS-owned Files Asset Files owned by the Operating System of a particular Network Host. localhostWorkstationEntryPoint userWithValidLoginCredentialsTrust
userCredentialsAsset ASSET_001.003 User Credentials The Username and Password for a single User humanNatureEntryPoint humanTrust
userOwnedFilesAsset ASSET_401 User-owned Files Asset Files owned by a particular user. The content may be personal or business-related. localhostWorkstationEntryPoint userWithValidLoginCredentialsTrust

The above report of Assets is obtained from the model with this SPARQL query:

PREFIX rdf: <>
PREFIX owl: <>
PREFIX xsd: <>
PREFIX rdfs: <>
PREFIX threat: <>

SELECT ?asset ?identifier ?name ?description ?entryPoint ?trustLevel
	WHERE { ?threatModel a threat:ThreatModel;
		<> ?title;
		threat:addresses ?system.

	        ?system a threat:System;
			<> ?extTitle;
			threat:integrates ?assetAccessProvider.

	        ?assetAccessProvider a threat:AssetAccessProvider;
			threat:providesAccessTo ?asset;
			threat:providesEntryVia ?entryPoint.

	        ?asset a threat:Asset.
			OPTIONAL { ?asset <> ?identifier. }
			OPTIONAL { ?asset <> ?name. }
			OPTIONAL { ?asset <> ?description. }

	        ?entryPoint a threat:EntryPoint;
			OPTIONAL { ?entryPoint threat:prescribes ?trustLevel. }

		FILTER( str( ?title ) = "RLIA Threat Model" )
	ORDER BY ASC( ?name )

p=. SPARQL Query of Assets within the RLIA Threat Model.

Trust Levels

Trust levels represent the access rights that the application grants to external entities — or the lack of trust the application holds for stranger and persona non grata entities. Elsewhere in this Threat Model, the Entry Point and the Asset tables reference the Trust Levels enumerated in this section. Trust levels are documented in the threat model as follows:

A unique number is assigned to each trust level. This is used to cross reference the trust level with the entry points and assets.
A descriptive name that allows one to identify the external entities that have been granted this trust level.
A textual description of the trust level detailing the external entity who has been granted the trust level.

The Rational Lifecycle Integration Adapter for PTC Windchill PLM is a typical federation of web servers and web application services. Therefore, the set of actors who might interact with the system — for intended or for unintended purposes — includes a typical community of unknown, untrusted actors and of authenticated, trusted actors.

The collection of Trust Levels for this RLIA Threat Model is available online within the “OSLC Threat Model” ontology and ABox repository at the Stanford WebProtege site.

This query of the current Trust Levels:

PREFIX rdf: <>
PREFIX owl: <>
PREFIX xsd: <>
PREFIX rdfs: <>
PREFIX threat: <>

SELECT ?identifier ?trustLevel ?description
	WHERE { ?trustLevel a threat:TrustLevel;
		<> ?identifier;
		<> ?description. }
	ORDER BY ?identifier

Yields these Trust Levels:


Table: Trust Levels

Determination and Rank of Threats

This section determines and then ranks the impacts of foreseen threats against the Rational Lifecycle Integration Adapter — nothing can be presented about threats which remain unforeseen. Before stating the identified threats and their impacts, the section provides the tactics and methods for threat categorization and for threat impact assessment.

Threat Categorization

Aiding in the determination of threats, a threat categorization taxonomy provides a set of threat categories with corresponding examples so that threats can be systematically identified in the application in a structured and repeatable manner.

According to ISO/IEC 15446:

"Once the informal security requirement has been documented, and the attacks and attributes identified, the next logical step in preparing a security problem definition is to perform a threat analysis to identify the threats represented by the potential attacks. ISO/IEC 15408 does not prescribe any particular methodology for identifying applicable threats. However, the methodology must identify all the threats perceived as relevant to the TOE in question."

Given this lack of prescription for a particular classification of threats in the ISO/IEC documentation, this Threat Model adopts as an adequate tactic Microsoft Research’s STRIDE categorization of threats. See Hernan 2006.


STRIDE is an acronym for the categorization of threats that identifies an attacker goals as one or more of: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, or Elevation of privilege (STRIDE).


Spoofing is threat action aimed to illegally access and use another user’s credentials, such as their username and password.


Tampering is threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet.


Repudiation is threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations.

Information Disclosure

Information Disclosure is threat action to read a file that one was not granted access to, or to read data in transit.

Denial of Service

Denial of Service (DoS) is threat aimed to deny access to valid users, such as by making a web server temporarily unavailable or unusable.

Elevation of Privilege

Elevation of Privilege is threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system.

Threat Impact

This threat model adopts the DREAD tactic for assessing the impact of realized risks. In the DREAD threat-risk ranking model, the technical risk factors for impact are Damage and Affected Users, while the ease of exploitation factors are Reproducibility, Exploitability and Discoverability. This risk factorization allows the assignment of values to the different influencing factors of a threat. To determine the ranking of a threat, the threat analyst has to answer basic questions for each factor of risk, for example:

Each parameter of Risk Impact assessment is scored numerically from 0 (least) to 10 (most); the scores for the parameters are then summed and averaged. A Threat with an Impact of 10 (greatest) is more significant that one with an Impact of 0 (least).

Threat Likelihood

A third parameter of the risk assessment method in this Threat Model is Likelihood, that is how probable or improbable is the realization of the potential threat.

To attempt to objectively quantify subjective uncertainty, this Threat Model uses the following expression for probabilistic-weighted risk level:

Risk Level threat = Likelihood threat * Impact threat

Likelihood probabilities range from 0% (never) to 100% (always).

Risk Likelihoods
Probability Description Likelihood of Occurrence
(0-20%] Rare Highly unlikely, but it may occur in exceptional circumstances. It could happen, but probably never will.
(20-40%] Unlikely Not expected, but there’s a slight possibility it may occur at some time.
(40-60%] Possible The event might occur at some time as there is a history of casual occurrence.
(60-80%] Likely There is a strong possibility the event will occur as there is a history of frequent occurrence.
(80-100%) Almost Certain Very likely. The event is expected to occur in most circumstances as there is a history of regular occurrence.

Itemization of Threats and Risk Levels

With a framework described for the categorization, impact, and likelihood of threats, this section now states for the Rational Lifecycle Integration Adapter the threats, their agents, methods, and assets, and their risk levels. A threat tree is employed and the initial nodes are the six STRIDE threat categories.

Threat of Spoofing (the S in Stride)

Scenario Summary: an anonymous actor attempts to spoof the identity of a known and trusted actor in order to obtain the credentials of that other user. If the credentials are obtained, the actor can then proceed to elevation of privilege threats to obtain more valuable assets.

For example, Cheapo Carts, Inc, a competitor of Acme Smart Carts, hires Henry Hacker to try to gain access to Acme’s PLM system.

Threat of Tampering (the T in sTride)

Scenario Summary: a trusted actor — or an anonymous actor fraudulently using the credentials of trusted actor — attempts to modify
the specification of the component materials or software of a system such that manufactured instances of the system are inoperable or perform malicious objectives.

For example, Cheapo Carts, Inc, a competitor of Acme Smart Carts, hires Henry Hacker to try to gain access to Acme’s PLM system to change the specification of the ball bearings in the wheels of Acme’s market leading cart from durable stainless steel to brittle pig iron. Henry uses a Information Disclosure attack to gain the credentials of Acme’s Physical Designer, Ivan Incorruptible. With Ivan’s credentials, Henry proceeds to execute a tampering attack to modify the PLM’s specification for the bill of materials for the Acme cart.

Threat of Repudiation (the R in stRide)

Scenario Summary: a trusted actor — or an anonymous actor fraudulently using the credentials of trusted actor — attempts to change the state of work item to shift blame away from their role in prior decisions to a colleague and to avoid leaving a record of such changes.

For example, Acme Smart Carts has been forced to issue a Safety Recall for their popular Tike Cart, a toy golf pull cart for children ages 5 to 12. National media has reported that the children pulling the carts behind their parents can trip and impale themselves on the supports of the Tike Carts. Penny Pecuniarius, a new procurement specialist on the Tike Cart team ignored Ivan Incorruptible’s recommendation to use a more expensive but safer design for the supports. After watching the evening news, Penny attempts to execute a repudiation attack to change one of last year’s Change Request notices such that it shows Penny not Ivan to be the Creator and Ivan not Penny to be the one who Closed the Change Request as Wont Fix.

Threat of Information Disclosure (the I in strIde)

Scenario Summary: an anonymous actor attempts to obtain information such as user credentials or product information by monitoring side channels ( Chen 2009 ) of the communication media in use by legitimate users. Information gained is then used for a spoofing threat or is sufficiently valuable on its own.

Threat of Denial of Service (the D in striDe)

Scenario Summary: a trusted actor — or an anonymous actor fraudulently using the credentials of trusted actor — attempts to send a barrage of requests to service access points in the system with the goal of so over utilizing one or more servers such that the overall system fails to offer service.

For example, Cheapo Carts, Inc, a competitor of Acme Smart Carts, hires Henry Hacker to conduct a DoS attack against Acme’s PLM and ALM servers to stymie Acme’s production process long enough for Cheapo to get its inferior, less popular carts to golf accessory retailers before Acme’s carts during the peak US Open season.

Threat of Elevation of Privilege (the E in stridE)

Scenario Summary: a trusted actor — or an anonymous actor fraudulently using the credentials of a trusted actor — successfully accomplishes information disclosure and spoofing threats to obtain access rights broader than appropriate for their role.

For example, Cheapo Carts, Inc, has hired Harry Hacker to shutdown the network host for Acme Smart Carts' PLM server. Harry starts hanging out at Carl Careless' favorite bar and learns that Carl signs all his tabs as “careless” and is dating Vivian Vivacious. Soon thereafter, Harry visits Acme Smart Cart while dressed in a business suit. He sits in the lobby with the other supplier representatives waiting to meet with Acme’s physical designers and chats with them about how well they are making quota this month. Shortly thereafter, he gets out his WiFi laptop and starts surfing He finds a link for Careers at Acme, then there one for Human Resources, then there one for Benefits, and finally there one for Employees My Benefits. He clicks that one. He is challenged for a login, he enters Username “careless” Password “vivacious” and the HR web server welcomes him to Carl’s medical benefits area. Harry has now elevated his privilege from untrusted, anonymous outsider to that of trusted, known user within one of Acme’s internal systems. (Eventually Harry will go on with his exploit of human nature and of Acme’s network security to gain the OS admin rights he and Cheapo seek.)

Controls and Countermeasures

Having provided a threat model with identification of the potential threats, the assets sought, the adversaries, and their means of entry, this section reviews the Controls and Countermeasures that are in place for the Rational Lifecycle Integration Adapter to mitigate the impact of these threats and to lessen the probability — if not prevent — their occurrence.


ISO/IEC 15408. Common Criteria for Information Technology Security Evaluation Part 1-3 December 2009.

ISO/IEC TR 15446. Information technology – Security techniques – Guide for the production of protection profiles and security targets, 2009.

ISO/IEC TR 19791. Information technology – Security techniques – Security assessment of operational systems, 2005.

ISO/IEC TR 13335-1-5. Information technology – Guidelines for the management of IT Security, March 2010.

ISO/IEC 27001. Information technology – Security techniques – Information security management systems – Requirements, 2013.

ISO/IEC 27002. Information technology – Code of practice for information security management, 2013.

Caceres 2006. Study on a Threat-Countermeasure Model Based on International Standard Information, 2006.

Hernan 2006 Uncover Security Design Flaws Using The STRIDE Approach, 2006.

Chen 2009 Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow, 2009.

OWASP REST 2014 REST Security Cheat Sheet.