Secure-Software Development: International Space Station Project

Development Team Project: Design Document

For this module, I had to position myself as an IT Software Consultant and a Developer. This project was designed to be realised as a team work. For the assignment, we had to develop an application for an organisation with domain-specific requirements. As a team, we have decided the following domain:
The International Space Station (ISS) (NASA, 2007).

During the development process, we completed the project in two phases a design and implementation phase. During the design phase, we considered the functional and non-functional requirements of the system and domain. Then, we considered the security implications of these features. We wanted to follow the best practice advice of academics and leading experts. We choose the open web application security project as well as Saltzer and Schroeder Security Principles as important references for guidance. During the design phase - and development of the design document- we considered the attack surfaces of our design. We identified the database, REST API, command-line interface, authentications systems as well as Python itself and the library’s used as attack surfaces worth attention. At this point in the project, we documented mitigations we thought appropriate. When we reached the implementation stage, we re-evaluated this result and used it as the starting point for implementing security features.

Our system features have two locations, earth and the ISS. Our system has two types of users: ground control staff and astronauts. The ISS has an inventory of resources – such as oxygen and food supplies - required to keep the space station running. There are two types of flights between earth and the ISS: manned and unmanned (NASA, 2010). Interfaces between the space station, ground control and the server will use secure facilities. The project will be developed as a distributed client-server web application, and will also run as a monolithic project (Al-Debagy & Martinek, 2018).

In reality, the location of the ISS during its orbit has an effect upon which system options are available, such as when a shuttle can be launched (NASA, 2007). In our system, we will assume the ISS is always at a convenient location for shuttle launch and communication.

Functional requirements:

• Both users will have a different interface to access the features specific to them.
• Ground control can create astronaut accounts. Ground control oversees shuttle flights (shuttle location, travel percentage, etc.).
• Ground control can add astronauts to space ships and send them to and from the ISS.
• The astronaut's interface allows them to access the exercise regimes which monitors their performance.
• The astronauts can see their performance metrics and the ground control users can oversee all the performance metrics of the astronauts.
• The ISS automatically orders resources that are running out. When a resource has been ordered, it is added to the next flight to the space station.
• Ground control initiates the manned flights, the unmanned flights are scheduled periodically to transfer any pending orders of resources.
• There are a fixed number of docks on the ISS and the flight/docking system ensures that flights are not organized to dock at the same dock.

Non-Functional requirements:

• The system will be available for use 24 hours a day, 7 days a week.
• Regulatory – The project will comply with the GDPR
• Security - Mitigations will be taken to protect the attack surfaces and sensitive data
• Recoverability –The system mustn't crash. We will use error handling to catch exceptions and handle them appropriately. We will make our database transactions ATOMIC so that if any part of the transactions fails the whole transaction is cancelled and no fragmented data is added
• Maintainability – We will use good OOP practices to keep the codebase maintainable. We will provide some documentation to help other developers understand the system.
• Domain-specific requirements - Data transfer will be affected by latency, as the ISS is a considerable distance from the control office. In addition, there will need to be a backup internet connectivity service in the event the main internet service fails. We do not want to lose communication between the ISS at any stage.

We will use the HTTPS secure protocol for communications to the server because this protocol enables secure communications (Krishna Madasu & Eltaeib, 2015).

Web applications that are not properly secured threaten the data and privacy of users. We have made use of the OWASP Top Ten security risks (OWASP, 2017) to help us identify security threats relevant to our system:

Surface	Vulnerability	Mitigation(s)
Database	We plan to use an SQL database; this would be vulnerable to injection attacks. The ‘principle of least privilege’ will be applied to ensure all code modules and users only have access to what is necessary.	We will encrypt data so it is useless to anyone without the key. We will make use of a database layer that enforces correct usage. Additionally, we plan to use the ‘salting’ (hashing with additional characters) technique for password storage (Bambang Sugiantoro, 2019).
REST Api	We plan to use a Flask Rest API. This REST API would be vulnerable to denial-of-service attacks	We will encrypt the communications between the client and server. We will use monitoring to monitor the request frequency of API calls to try and identify DOS (denial of service) attacks (Prakash et al, 2016).
Authentication	The users of our system have a lot of responsibility when organizing flights and resources. It is of paramount importance that our system has adequate restrictions for authenticated users.	Different levels of access control will be provided to different user types. We will use multi-factor authentication to avoid broken authentication.
Command-line interface	Our system will allow users to share data entered through the interface. This opens a vulnerability to cross-site scripting where malicious users can inject malicious code through the client interfaces.	We will use input validation on any user input. We will also be careful that our input validation itself is not susceptible to attacks such as a Regular expression Denial of Service attack (Kirrage et al, 2013).
Python and additional library's	Python has known vulnerabilities such as its dangerous ‘pickling’ features. We will make use of third-party libraries to develop our system. These libraries can have their own vulnerability's.	We will research any vulnerabilities of libraries and python features we use.

We decide to use this non-exhaustive list of tools and libraries for our project:

• Python3
• SQLite database package
• Flask (RESTApi library
• Cryptography
• PyCharm IDE

Our system will be designed to work in a client-server architecture as well as a monolithic architecture. Both designs will make use of a three-tier architecture for the separation of concerns (IBM Cloud Education, 2020). The three tiers will be, interface, business and data storage. Monolith designs require the whole system to be updated at once, the client-server architecture, however, will allow either of the clients or the server to be updated individually. We will avoid ‘anti-patterns’ in our code (Jaafar et al, 2015). We will use design patterns to allow us to create modular code that is extensible and easily understood by other developers. Appropriate Design Patterns:

• Strategy design pattern – This pattern allows for the dynamic choice of an algorithm to be executed. This could be useful for our exercise system where a different algorithm may be executed based on which exercise regime is selected.
• Adapter design pattern – The adapter pattern allows two incompatible interfaces to communicate. This pattern will be very useful for converting to and from the ‘transport’ layer for client-server communication purposes.
• Observer design pattern – The observer pattern decouples the observers of events from the subject. The observer pattern may be useful for the ISS resource management feature. For example, observers may subscribe to an ‘oxygen low’ event.
• Singleton pattern – The singleton pattern is a way of ensuring only one instance of a class exists. Considering that our system will only every have ‘one’ ISS this pattern may be useful.

During design and implementation, we will ensure compliance with the GDPR (General Data Protection Regulation) (Hoofnagle, Sloot and Borgesius, 2019)(Knott, 2018). As such, the following protocols will be put in place:

• Designate a DPO (Data Protection Officer) (Murphy, 2018).
• Software design focus on the protection of privacy and personal information (Lambrinoudakis, 2018). This includes all medical and exercises history relating to astronauts and other employees(Voigt and von dem Bussche, 2017).
• All personnel information will be protected from unauthorized access as well as be pseudo-anonymized, as well as encrypted. This includes but is not limited to names, identity numbers, date of birth, address, contact details, pay, bank information, education, and position. All former employees’ information shall be afforded the same privacy (Martin & Kung, 2018)
• Internal communications shall be kept private and secure through encryption. (The design of all communications methods will follow these principles.)
• Any data breach requires individuals to be notified and an investigation to begin immediately (Lambrinoudakis, 2018).

We consider the users passwords, exercise performance metrics and the ISS inventory to be critically sensitive data (Gholami & Laure, 2016). Data such as shuttle location are considered less sensitive. We have highlighted that the data and measurement of the oxygen are mission-critical and mistakes could cause serious harm. We have decided to use a system watchdog (Lou et al, 2019) that will monitor the performance to make sure the software is working as expected. This watchdog will monitor that the data changes at the expected rate, I.e., The oxygen level reduces.

In our design, we used UML modeling and then, we implemented that design. On the left, we can see the class diagram.
click on the image to make it bigger

On the right hand side, we can see how we created the activity and entity relationship diagrams.
click on the image to make it bigger

Development Team Project: Final System Version

Our system architecture uses a client-server design with a 3-tier layered structure. Our client applications form the interface layer. The server implements the business and datastore layers. We chose to use the Pycharm IDE tool for development, due to its robust lintings feature which can assist code development.

The Logging part is important to the creation of a secure software system. Logs can provide insight into the operation of the system and can aid debugging exercises. We have decided to log all calls to the server to provide information about the system's usage. We have implemented a vulnerability assessment as part of the live system. The system routinely executes a vulnerability assessment of the python packages used. This check involves comparisons with a vulnerability database. The result of this assessment is stored in a file called 'safteylog.txt'.

We have used the HTTPS secure communications protocol to securely communicate over the network. HTTPS builds upon the HTTP protocol and uses either TLS or SSL for transport layer security. This protocol uses a form of public-private key encryption. Our client applications have access to a public certificate that signs our requests. Access to many of the endpoints is further restricted to only users that have been granted an 'advanced privilege key'. This key is only transferred to the user when they provide a correct pair of email and passwords. The key is sent over the network secured by the use of HTTPS and stored for the duration of the session on the client. The only two endpoints that do not require this key's authorization are the two endpoints required for the user to log in.

For the data access layer, we have used SQL constraints in data access layer to further secure our data’s integrity. The use of constraints seen here such as NOT NULL and foreign id references ensures only valid data is inserted. It is important to validate that the users’ input is within the 'acceptable' range. In this code example, we see that users' email input is validated with a control structure that requires a server check of whether the account exists. RESTful interfaces are vulnerable to denial-of-service attacks over the internet. We have a monitoring feature that displays in real-time the number of calls being made to the server. If this frequency of calls is extraordinarily high, then we display a warning here to indicate an attack may be underway. We have set the threshold to 60 calls per 15 mins.

To prevent SQL Injection attacks, we have used SQL parameterised queries so that all the users' input is automatically escaped. This prevents malicious users SQL queries from being executed on the database. We have also used cryptography to help protect the database attack surface we identified. If the database is exposed the password contents is encrypted so that is not readily accessible. The contents can still be revealed if the attackers use a rainbow table to decrypt the stolen password information. The encryption however adds an extra layer of security and will at the very minimum provide additional time for other mitigations to be taken - for example notifying users of the breach.

If we would take this project further, here are few points we were thinking about:

• Our Flask server provides a synchronous service. If we were to scale the project up, we may want to use a server that can handle multiple concurrent requests, i.e., Asynchronous service.
• We may want to adopt a microservice architecture to help improve the projects scalability/modularity, as the project grows.
• We may want to consider using different programming languages of different paradigms that are most suitable for their specific applications, i.e., functional languages could help with scalable concurrency.
• The work we have done so far resembles the first sprint of an agile development process. Before proceeding to the next phase of development, we would want to consult with the project stakeholders to assess how closely the proposed prototypes meet their needs. We would want to use a form of secure SCRUM going forward.