Converting the framework to match current baselines

The alpha version of the third version of the framework lays the foundation of the actual third version of the framework. The third version of the framework consists of a baseline. While converting the alpha version into the baseline, two problems were encountered. Each problem and their solution will be discussed in this section. After the problems and solutions are clear, the process of converting the baseline will be discussed.

Sheet and macro protection

The template which I wanted to as a foundation for my baseline was protected. I was not able to edit any cells or macros without knowing a password. I made an attempt at removing this password using a Hex Editor, but that failed. I asked the Secure Development Corodinator whether they could help me out with this. They suggested that I planned a meeting with a Cybersecurity Consultant who would help me out with this. The meeting happened after the delivery deadline for the baseline, which is why it was not possible to deliver the baseline in time. The outcome of this meeting was that the Cybersecurity Consultant sent me an unprotected version of the sheet, which I was able to edit without problems.

Re-appearing protection

The Excel sheet has two buttons, one to fill the baseline, and one to empty the baseline. Pressing any of these two buttons would re-enable the protection, there- fore defeating the purpose of the unprotected sheet. After more e-mails with the Cybersecurity Consultant, I was able to obtain the password to undo this protection. With this password, I removed the re-appearing protection by editing the macros responsible for this. Finally, I was able to create and deliver the baseline, albeit later than planned.

Creating the baseline

After the problems were solved, the baseline was ready to be made. The format of the baseline was similar to the format the framework was already in, but required some modifications. It was also more focused on controls rather than threats. The first modification consisted of an extra field. This was a “Control ID", which is the unique identifier for the control. I decided it would be best to keep this in line with the already existing baseline and give them names like “GLOBAL-8" and “LOG-MANAGEMENT-TOOL-2", meaning the eighth control in the global category of threats and the second control of the log management tool category of threats respectively.

The second extra field was named “Control Group", which determined in which group a certain control would belong. Since I already grouped threats according to

the STRIDE methodology previously, I decided it would be best to fill this field with the STRIDE group that the control was meant for.

The third extra field was named “Name". This is the name of the control. In a couple of words, this would describe what the control was all about. I decided to take a look at existing names and base my names on that.

Fourthly, there was a “Description" field. I copied this pretty much one-to-one from the existing framework. This worked in most cases, with some minor edits necessary to make things more clear.

The fifth difference was an extra field named “Context". This would give some more context about the meaning of the control. I filled this field with some information to provide context to the reader.

The sixth difference was an extra field named “How to check". This is a field meant for the auditor, which indicates how to check that a control is properly implemented. I filled this field with exactly that information.

The seventh difference was that there were extra fields named “Compliant", “Applica- bility", “Mandatory", “Same control" and “General". These were presumably used by the macros to do some behind-the-scenes things. They were left unaltered, with the value for “Compliant" always being “Compliant", the value for “Applicability" always being “Always", the value for “Mandatory" always being “X", the value for “Same Control" always being empty and the value for “General" always being “H".

The eighth difference was a field named “Prio", which indicated risk levels. This was directly copied from the framework.

The baseline marks the end of three iterations of the Design Cycle. In the next section, we will discuss these results.

6

Discussion of Results

6.1

Implication

The objective of this research was to develop and validate a framework, that aims at preventing and detecting security vulnerabilities in Continuous Integra- tion/Continous Delivery pipelines. To make this happen, we firstly have determined the scope of the research to be “Managed Production Line environments provided by the company to customers" together with experts from the company. Then, we proposed an initial version of the framework with threats and controls based on several sources. Using feedback we gathered from an expert within the company, the second version was delivered. In an evaluation meeting with two experts, more feedback was collected. Together with the results of the risk level evaluation meeting and validation on who is responsible for implementing each control, this resulted in the third and final version of the framework. This version was validated by experts, who said that the framework was ready to be adopted into the baselines. The new framework has significant implications on the use of the managed Production Line for the company, provided that it is used effectively.