Let's do an example
Saban Safak
Software Compliance Verification Engineer (Senior Chief) @ ?????????????? {CSQE, CSFE} - Yapay Zeka Terbiyecisi
Security requirements define new requirements or additions to existing system requirements to address security issues or mitigate exploitable vulnerabilities.
Security requirements are derived from industry standards, applicable regulatory requirements, and a history of exploited vulnerabilities in the past.
According to DO-356/ED-203 security requirements should be implemented in the design in a way so that safety and security are coordinated.
DO-356/ED-203 also defines that security requirements may be analogous to derived requirements because, usually, there are no higher-level requirements or aircraft/system functions as a source to the security requirements.
It is also important to note that security requirements may consider both safety and business needs
Software-Field-Loader-Over-the-Air
Imagine an aircraft system that capable software upload to the LRU using field-loadable capabilities without removing the hardware from the aircraft.
The transfer medium could be USB or WI-FI.
Selected threat is "Unlicensed data being loaded into the system”
Three security threat scenarios
Ten security requirements with their respective test scenarios:
001 The system wireless device shall connect to the configured access points using WEP 128-bit security protocol.
- Scenario 1: Verify that the system can connect to an access point using WEP 128-bit security protocol.
- Scenario 2: Verify that the system cannot connect to an access point using another security protocol.
002 The system USB interface shall transfer data only with devices that are USB MSC (Mass Storage Class) compliant.
- Scenario 1: Verify that the USB interface interfaces with devices that are compliant with USB MSC.
- Scenario 2: Verify that the USB interface does not connect with devices that are not compliant with USB MSC.
003 The system shall create a history log containing the following information:
领英推荐
- Scenario 1: Analyze the history log to check if only the required information was recorded.
004 The system shall write down, in a history log, successes and failures attempts of authentication to access the system.
- Scenario 1: Analyze the history log to check if all authentication attempts were recorded, including the unsuccessful ones.
005 The history log shall be protected from modifications.
- Scenario 1: Attempts to modify the recorded information in the history log shall be performed to check if it is protected against modifications.
006 The USB interface shall be deactivated when the aircraft is on the flight.
- Scenario 1: Verify that the USB interface is disabled when the aircraft is on the ground, and the discrete is disabled.
007 A firewall mechanism shall be configured in the system wireless interface.
- Scenario 1: Analyze that the firewall is properly installed and configured in the system.
- Scenario 2: Verify that the firewall is properly working as configured.
008 The system shall permit only software applications presented in the whitelist to be installed on the operating system.
- Scenario 1: Verify that all applications presented in the whitelist were properly installed on the system.
- Scenario 2: Verify that an application outside the whitelist was not installed on the system.
009 The system shall permit loading of an application placed into the system only if the aircraft is on the ground and the physical mechanism is enabled.
- Scenario 1: Verify that the system allows application loading according to the provided table.
010 All the authentication access to the system shall be comprised of a username and password.
- Scenario 1: Verify that the system allows access only to a valid username and password.
- Scenario 2: Verify that the system denies access to an invalid username and/or password, including blank values.
These scenarios cover various aspects of the system security functionality and provide a basis for testing against the specified security requirements.