Example Evaluation

We present an information technology (IT) system to illustrate the usefulness of structural security posture for evaluating design decisions. We adapt the example of the Online Seller of Merchandise (OSM) system presented in [QRS2021].

The OSM system has the following system elements:

• Web Client: A web-based interface for customers to interact with the OSM system.

• Web Server: Orchestrates the purchase process initiated by the customer and serves the relevant information (such as order status, shipping status, items available) to the Web Client.

• Identity Access Manager: Ensures the customer is authorized to perform the actions they are requesting (such as placing an order for an item).

• Customer Datastore: Stores data related to the customers registered with the store such as name, contact, credit card information, and address.

• Customer Manager: Ensures customer information is present in the Customer Datastore for the order to be processed.

• Transaction Processor: Processes the payment using the customer’s details such as name, address, and credit card information.

• Inventory Datastore: Stores data related to the various items available in the store such as available stock and price information.

• Inventory Manager: Ensures the stock required is available for the order to be processed and that the requested quantity of the item(s) is shipped and accounted for in the Inventory Datastore following a successful transaction.

• Shipment Processor: Facilitates the shipping for the ordered items by coordinating with the Inventory Manager to ensure the stock required is available and the number of items shipped is accounted for in the Inventory Datastore following a successful transaction.

• Order Processor: Processes the incoming order of one or more products by ensuring the required information from the customer such as their credit card information is on file (through the Customer Manager), processing the payment for the order using the Transaction Processor, and passing that information to the Shipment Processor to ship the requested product(s).

We represent the structural view of the system using the UML class diagram notation shown below.

Note

We only describe the elements of the OSM system critical to a simple transaction (one where the product(s) requested are available and customer information is available for the order to be processed) as this is sufficient to illustrate our contributions.

Tip

You can download the files generated by this analysis and import it into Polaris to view the results for yourself.

• Original Design

• Transformation #1

• Transformation #2

• Transformation #3

Let’s suppose that Alice is the system architect responsible for designing the OSM system. The system’s objective is to allow registered customers to browse the store inventory and purchase one or more products. Alice already sketched out an initial design for the OSM system shown above. However, she aims to improve her initial design in terms of security.

Alice’s goal is to evaluate different design decisions to design an adequately secure system. Doing this during the OSM system’s design phase means that Alice can iterate over the design to improve its security without incurring additional overhead or costs.

Alice is aware that most attacks targeting information systems like the OSM system tend to follow the data (especially sensitive data) [IEEE2019], so she focuses her initial efforts on securing the Customer Datastore as it contains highly sensitive and valuable information that needs to be protected. The Customer Datastore is also critical to the functionality of the OSM system as customers who are not authenticated cannot place an order.

Alice adapts the attack surface parameters for the elements of her system to be the same 1-to-10 scale chosen by Gennari and Garlan in their attack surface example [CMU2012]. The interpretation of the chosen scales for each element type is shown in the table below. Transmission Control Protocol (TCP) is a type of internet protocol used to transmit information over the internet. Remote Procedure Call (RPC) is when a computer program executes an operation beyond its own address space (on a remote computer). For the purpose of this example, detailed knowledge of these protocols is not required. The larger the value chosen, the greater the advantage the attacker has to exploit an element. For example, a component with guest privilege will have significantly reduced privileges and therefore be assigned the lowest privilege value (1); a component with root privilege will have the least restrictive privilege and therefore be assigned the highest privilege value (10).

Components	Privilege	Value	Access Rights	Value
	root	10	root	10
	authenticated	5	authenticated	5
	guest	1	unauthenticated	1
Links	Protocol	Value	Access Rights	Value
	direct entry	10	local	10
	TCP	5	remote	1
	RPC	1
Datastore Items	Data Type	Value	Access Rights	Value
	SQL	10	root	10
	Inventory Data	1	authenticated	5
			anonymous	1

With her initial sketch of the OSM system, Alice uses the Design tab of Polaris to input her system model in preparation for her experiment. In her initial system design, the Web Client is able to directly communicate to the Customer Datastore through the Web Server and Customer Manager. While this is fairly straightforward to design and implement, it may have drastic implications on the security of the system. One example of the potential security consequence is the ability to perform SQL injection attacks if there is no input validation present. To model such scenarios, Alice chooses suitable values based on the above table as initial parameters for the elements of her system. The following table details the values chosen for the elements of the initial design of her system.

Component	Access Rights	Privilege
Shipment Processor	5	5
Transaction Processor	5	5
Customer Manager	5	10
Web Server	5	5
Inventory Manager	1	10
Identity Access Manager	5	5
Order Processor	5	5
Web Client	1	1

She assigns SQL (10) as the data type for Customer Datastore and authenticated user (5) as its access rights. Alice chooses SQL as the data type as she anticipates the Customer Datastore to hold a diverse range of information such as customer names, addresses, phone numbers, and credit cards which SQL supports. Unfortunately, this feature of SQL to support broad types of data also lends itself to hold unauthorized data in the Customer Database. A popular attack that takes advantage of this is called a SQL Injection attack where the attacker provides a SQL statement in place of regular text input (such as for name, email) [IEEE2006]. This attack works when the system fails to validate the input and passes the input SQL statement directly to the datastore which executes the unauthorized SQL statement. Alice set the datastore’s access rights to denote an authenticated user to only allow authenticated users to access their information from the Customer Datastore.

Alice wants to evaluate the structural security posture for the OSM system to determine if and how she can improve her system design. She uses Polaris to perform this experiment. Polaris allows Alice to perform ‘what-if’ analyses thanks to its automated computation of system-level and element-level metrics based on the chosen parameters.

Evaluation of the Initial OSM System Design

Alice initializes her OSM system design in Polaris as shown in the UML diagram earlier. Her evaluation of the initial design enables her to get a baseline for the structural security posture of the system. Since Alice has the initial security requirements and design decisions for the Web Client, Web Server, and Customer Datastore as shown in the table below, she annotates this information in Polaris. These requirements and design decisions can help Alice leverage external data sources in her analysis based on the approach presented in [IEEE2021].

Component	Security Requirements	Design Decisions	Unmitigated	Mitigated	Extraneous
Customer Datastore	Ensure access control policies are implemented allowing the datastore administrator to implement access policies for various datastore users and data contained within the datastore.	The database server will be MySQL and it will run on a Linux server. The database server will use SQL to query the database.	1030	1195	0
Web Client	Ensure all customers are verified based on their credentials using login functionality.	Web Client will interact with a SQL database to populate the inventory page.	416	755	1
Web Server	Ensure all internal and external connections for the server go through an appropriate and adequate form of authentication. All protected pages must enforce the requirement for authentication and authorization.	Web server uses NGINX proxy and Linux.	119	519	0

In her initial analysis, contributions from the components of the system towards the attack surface was 18, contributions of links towards the attack surface was 65, and contributions of datastore items was 2.2. The Web Server gets the highest centrality ranking of 0.55 followed by the Customer Manager at 0.44, Web Client at 0.19, and Customer Datastore at 0.15.

The element-level metrics (i.e., eigenvector centrality) of the structural security posture evaluation can help Alice to identify potential weak points in the design that could have negative security implications.

Recall from Eigenvector Centrality Metric that a system element’s eigenvector centrality ranks its importance in the system relative to the importance of its neighbouring elements. She notices that out of all the elements likely to be involved in a SQL injection attack, the Web Server is likely to be an important target followed by the Customer Manager based on their centrality rankings. This implies that, should an attacker manage to compromise the Web Server or the Customer Manager (or worse, both!), they can access and communicate with other important system elements in addition to the Customer Datastore. Since the Web Server and Customer Manager have the potential to enable such attacks on the system, Alice extends her focus toward protecting these elements. Alice correlates the analysis results with the privilege level she assigned for the Web Server in the initial design. Initially, the privilege level of the Web Server was assigned as an authenticated user (5) which means that an attacker can have the privilege level of an authenticated user if they compromise the Web Server. This would allow an attacker to access functions associated with that privilege level and will likely be able to maliciously affect other components that also require the privilege level of an authenticated user (5).

These results also show that there is a significant contribution from the links in the design towards the overall system’s attack surface. The contributions from components are also something Alice wants to pay attention to when revising her design to ensure she does not increase it significantly. The positive news here is that the contributions from datastore items towards the overall attack surface in Alice’s initial design is significantly low (2.2). This means she can shift her focus towards components such as the Customer Manager and Inventory Manager which interact with their respective datastores to improve the system’s overall security.

The data-driven threat metrics from Merak point Alice to potential attacks that could affect the Web Client, Web Server, and Customer Datastore (elements she annotated with requirements and design decisions). As she reviews the unmitigated threats for the Web Client and Customer Datastore, she notices a common type of attack across various threats; an SQL injection attack, which confirms her initial intuition. We present a snippet of the threat analysis results from Merak’s analysis in the figure below, based on the security requirements and design decisions for the Customer Datastore detailed above. In the threats listed, we can see that CVE-2021-2385 discusses a vulnerability that allows a highly privileged attacker with network access to compromise a MySQL Server such as the one Alice intended for her Customer Datastore and Inventory Datastore. Additionally, we can see references to SQL Injection vulnerabilities affecting an e-commerce website in CVE-2021-25205 similar to what Alice intends to design and develop. Having this type of information during the design phase helps Alice to better understand the threat landscape of her yet-to-be-implemented system which helps her focus her attention on specific areas of the system such as elements that deal with SQL data or handle input data in general. It also helps her think about suitable mitigations that can be instituted in the design prior to the system’s implementation.

With her baseline now set, Alice comes up with a few alternative transformations for her design that she suspects can mitigate a SQL injection attack:

• Modify the access rights, privileges, and protocols of the system elements involved in conducting such attacks.

• Create a Data Sanitizer component to sanitize the input from the Web Client before it reaches the Customer Datastore.

• Apply a combination of the above transformations.

She suspects that the ideal solution may be a combination of the above strategies to mitigate SQL injection attacks (and similar attacks that exploit inputs). Since it is hard for Alice to concretely determine to what extent each mitigation strategy needs to be employed, she decides to use the ‘what-if’ analysis feature of Polaris to experiment with the possible security outcomes of each alternative. Such an analysis can help her discern what values to assign for the access rights, privileges, and protocols of the system elements (i.e. components, links, and datastore items) involved in such attacks. She can also evaluate how different values impact the overall system’s structural security posture. She also wants to see if changing these values or the structure of the design has any unintentional impact on the security of other system elements.

Alice applies each of the above transformations and evaluates the change in the system’s structural security posture, as follows.

Transformation #1: Experimenting with Parameters of the OSM System Elements

Alice’s objective with the ‘what-if’ analysis is to determine the parameter values for system elements that collectively minimize the overall system’s attack surface. With Polaris, Alice is able to evaluate how different access rights, privileges, and protocols can impact the overall attack surface of the system and to what extent.

During Alice’s experimentation with different parameters, she changed the privilege level associated with the Inventory Manager and Customer Manager from root (10) to an authenticated user (5) since root privileges were simply not required to perform Create, Read, Update, Delete (CRUD) operations with their respective databases and instead increased the system’s attack surface.

During her analysis, Alice also noticed redundant links between components. One such set of links connects the Identity Access Manager and Transaction Processor to the Customer Manager. These links are considered redundant as the Identity Access Manager and Transaction Processor can communicate with the Customer Manager transitively through the Web Server. Similarly, Alice identifies a redundant link connecting Shipment Processor to Inventory Manager. Alice decides to prune such links in addition to applying her new set of parameters as part of this transformation. The new structure of the OSM system after making these changes is depicted below.

The transformations already show an improvement in the system’s attack surface. Contributions from the components of the system towards the attack surface reduced from 18 to 12 and contributions of links towards the attack surface reduced from 65 to 50. With regards to centrality, the Web Server still has the highest centrality ranking of 0.64 followed by the Customer Manager at 0.32, Web Client at 0.26, and Customer Datastore at 0.13.

The importance of the Web Client, Web Server, and Customer Datastore increased as the importance of their neighbouring elements increased due to the removal of redundant links which reduces the paths to certain elements and increases the importance of elements that form that path. The Customer Manager was the exception but only by a margin of 0.01 which is not significant relative to the centrality values of the other critical elements.

Transformation #2: Sanitizing Data Inputs

To help mitigate input-based attacks such as SQL Injection attacks, Alice decides to introduce two new components responsible for data sanitization, one between the Web Server and other components of the system which she names Gatekeeper and one between the Web Client and the Web Server which she names Data Sanitizer. Both of these components act as gatekeepers to protect sensitive elements of the system by validating any user input.

Alice decides to incorporate the Data Sanitizer component locally with the Web Client to ensure that inputs are sanitized prior to their transmission over the network to the Gatekeeper. Alice reflects this by changing the access rights for the link connecting the Web Client and Data Sanitizer to local (10). She also sets the link connecting Data Sanitizer with Web Client to have the access rights of local (10) and protocol level of (10) as the communication between them will be through direct entry. The link connecting Gatekeeper to Data Sanitizer however communicates with access rights of remote (1) and a protocol level of TCP (5) which is more restricted than direct entry transmission.

Note that Alice applies these transformations on her original system model, resulting in the below results.

Alice notices that the attack surface increased from the baseline value of 18 to 20 for the components and from 65 to 66 for the links. The Customer Manager now has the highest centrality ranking at 0.42 followed by the Web Server at 0.19, Customer Datastore at 0.14, and Web Client at 0.07.

Alice notices how the Web Client and Web Server saw a significant reduction in their importance following the introduction of the Data Sanitizer and Gatekeeper components respectively. A notable observation here was how the Customer Manager was affected by the introduction of the Gatekeeper only by a small margin. However, Alice did expect this as the Customer Manager has more links than the Web Server and the Web Client, so the introduction of a Gatekeeper on one of those links, while helpful, does not make a significant change.

Transformation #3: Combining Transformations #1 and #2

To summarize the effects of Alice’s transformation so far, the first transformation on the initial design which pruned redundant links and reduced unnecessary access rights and privileges showed a significant reduction in the overall attack surface but it did result in an increase in the importance for a number of critical elements. The second transformation on the initial design which introduced two Data Sanitizer components showed a significant reduction in the importance of critical elements that were impacted directly by the Data Sanitizer but the overall attack surface increased.

In this third transformation, Alice proceeds to evaluate the combination of both of these transformations applied to the initial design at once. Her intuition is that this should result in a balanced overall reduction in terms of the system’s attack surface and the importance of critical elements.

Alice’s results from applying these transformations are shown below.

This transformation significantly reduced the attack surface of the system for both components and links. Contributions to the attack surface from components and links were reduced from 18 to 14 and 65 to 51, respectively. The Customer Manager still has the highest centrality ranking relative to the other elements at 0.29, followed by the Web Server at 0.25, and both the Customer Datastore and Web Client ranking at 0.11. However, Alice noticed a reduction in the importance of all of the elements (Web Client, Web Server, Customer Manager, Customer Datastore) that she sought to protect compared to her initial design. This means that the likelihood for an attacker to use the Customer Manager or other critical elements to affect other elements of the system is reduced.

Experiment Conclusions

A summary of Alice’s structural security posture evaluation is shown in the below table. Based on these outcomes, Alice believes Transformation #3, which is the combination of modifying element access rights, privileges, and protocols, pruning redundant links, and introducing two data sanitization components in her initial system design, provides a structural security posture adequate for her requirements. Thus, she chooses to apply Transformation #3 for her system.

Design	Attack Surface	Web Client Centrality	Web Client Centrality	Customer Manager Centrality	Customer Datastore Centrality
Initial Design	(18, 65, 2.2)	0.19	0.55	0.44	0.15
Transformation #1	(12, 50, 2.2)	0.26	0.64	0.32	0.13
Transformation #2	(20, 66, 2.2)	0.07	0.19	0.42	0.14
Transformation #3	(14, 51, 2.2)	0.11	0.25	0.29	0.11

This experiment shows how a system architect can evaluate different design decisions for their impact on system security using structural security posture based on requirements. This experiment also highlights the importance of providing adequate tool support to enable the system architect to perform the above evaluations.