To: Lord Vader
From: 5th Imperial Fleet Cybersecurity Unit
Subject: Death Star security failures

Executive Summary

This report outlines the results of our analysis of the security failures that led to the destruction of the Death Star by the Rebel Alliance (hereafter referred to as the “Alliance”) at Yavin. It is our conclusion that the loss of this capital asset
was the result of a string of failures, partly arising from human error, but also from systemic failings in Imperial security processes and system architectures, as well as fundamental design flaws. This has all been exacerbated by a culture of blame and
fear.

Fundamental principles of Information Security

In the report below, we adopt an essentially chronological view of the events leading up to the destruction of the Death Star, highlighting security failings as they occurred. However, it is regrettable that this represents a catalogue of errors that
violate almost every principle of Information
Security. The investigation has been made more difficult due to the fact that many of the personnel involved are deceased, and the investigative committee has had to piece together events after the fact.

To aid understanding of our analysis, we briefly recapitulate the basic tenets of Information Security here. Information security (sometimes referred to as Information Assurance) is concerned with maintaining the following properties for information and
assets:

- Confidentiality: preventing our adversaries, in this case the Alliance, from gaining access to our sensitive information (and also enforcing need-to-know principles among our own personnel as a further backstop – see the defence in depth discussion
below).

- Integrity: preventing the unauthorized modification of our data.

- Availability: Ensuring that information and systems are available for use as required.

Enforcement of these properties requires the adoption of a variety of security controls and processes, which form the fundamental building blocks of a coherent security approach. We consider how each of these failed below.

Death Star development

There were significant issues during the design and construction of the Death Star. It was already known that Galen Erso (Imperial research scientist and Death Star designer) was antipathetic to the Death Star project before he was coerced into rejoining
the project team by Orson Krennic (Director of Advanced Weapons Research for the Imperial Military). Erso therefore represented an insider threat. Yet he was still given unfettered and unsupervised responsibility for the design of the Death Star reactor
core. This allowed him to design in a vulnerability which was exploitable, and would therefore lead to a catastrophic failure of the reactor. In short, there was no division of responsibility for the highly classified work that was being undertaken.

Recommendation: Effective division of responsibility is instituted for all Imperial for classified projects.

Indeed, the culture of fear among scientists and engineers exacerbated the problem, and would not have encouraged any of Erso’s colleagues to report any concerns they might have had. This had its apotheosis during the execution of the engineering team,
ordered by Krennic on Planet Eadu for entirely arbitrary reasons.

Recommendation: The Imperial Military to implement a no blame culture in which concerns and mistakes are highlighted so that all can learn from them.

The sheer scale of the Death Star project rendered the development of prototype systems and test articles infeasible. This may have contributed to the failure of the authorities in spotting the vulnerability, and made have made it easier for Erso to
insert it.

Theft of Death Star schematics

The Alliance was able to steal the Death Star schematics, which would subsequently enable them to identify the Erso vulnerability. This is despite the fact that the plans were stored in a high security Imperial database on planet Scarif. Once again, a
catalogue of security errors contributed to the success of the Alliance operation.

The stolen Imperial shuttle used by the rebels to land on Scarif was permitted to cross the security perimeter despite using an old security code when challenged. This indicates that code rollover is not rigorously enforced, if enforced at all. Given the
regularity with which Imperial shuttles are stolen, this represents an unacceptable lack of security. Code replay is also not prevented, and we believe that such an antiquated system should be replaced.

Recommendation: Consideration be given to using challenge-response protocols for identifying Imperial ships in a timely manner.

Upon gaining access to the database facility, Alliance troops were able to retrieve the Death Star schematics with relative ease. Access to all files was possible from the database terminal within the facility, irrespective of sensitivity (a system of
codenames was the only obstacle to file identification, an example of the ineffective practice of security through obscurity). This indicates that database security was poor, something which pervades Imperial systems and which aided the escape of
Princess Leia Organa from the operational Death Star some weeks later (see below). Worse still, the plans were held on unencrypted, removeable media that allowed the rebels to extract a copy of the schematics. The Empire’s own communications network
was then used to transmit the schematics to an Alliance battlecruiser in orbit around Scarif, indicating that communications were also unencrypted. The subsequent destruction of the Imperial database by the Death Star, as ordered by Grand Moff Tarkin,
further failed to take into account the fact that there were no off-site backups.

Recommendation: All sensitive data stored on removeable media and when transmitted to be encrypted.

Recommendation: Imperial database systems to enforce fine grained access control.

Escape of Leia Organa

It is fair to say that the escape of Leia Organa from the Death Star, and more importantly, the R2 unit in which she placed the Death Star schematics, was instrumental in the final destruction of the space station. Yet again, a series of errors were made
which contributed to this.

The Death Star tractor beam, which initially ensnared the Corellian freighter containing the Alliance sympathizers, was disabled by the remaining Jedi (scum) Obi-Wan Kenobi. Kenobi was able to gain unsupervised access to the tractor beam controls (
compare this to the lack of supervision afforded to Erso, discussed above) and shut the beam down. No security cameras were present and the controls were located in an unmanned area, so his actions could not have been prevented. Nevertheless, had
sufficient system security monitoring been in place, the shutdown of the tractor beam (a security critical system) would have been detected and an alarm raised. Nor, apparently, was the shutdown of the tractor beam logged, or if it was, then insufficient
log analysis and audit was carried out.

Recommendation: All security critical systems should be subject to proper access control, monitoring and logging.

Recommendation: Log analysis droids to be used to identify security critical events in logs and to filter out false positives.

The location of Organa in the prison block, and subsequent escape of the rebel sympathizers from the garbage compaction system, was possible because a rogue R2 unit was able to gain full access to Death Star systems from almost any network port, without
any form of authentication. Further, the R2 unit was able to gain control of those systems. It would appear that Death Star networks and databases allow unauthenticated access to all areas, without any enforcement of the principle of least privilege to
limit the actions of any user. Firewalls appear to be entirely absent from the network design, which is unsegregated. Given the deficiencies of the Scarif database system discussed above, it appears that the Imperial military has failed to learn any of
the lessons.

Recommendation: Future Death Star systems to enforce access control, based upon authenticated identity and with the level of privilege restricted according to role (mandatory access control).

Recommendation: All network ports on Imperial vessels are locked down to specific, authorized MAC addresses.

Recommendation: A lessons learned exercise be conducted following destruction of the Death Star so that the same mistakes are not made again.

Finally, the escape of Organa might still have been prevented but for serious failings in both Stormtrooper equipment and Death Star design. Regarding the former, current Stormtrooper armour provides little visibility, is hot and uncomfortable to wear,
provides poor camouflage, and constrains movement considerably. These downsides would be acceptable if it were not for the fact that the armour appears to provide no protection from blasters whatsoever. Regarding the latter, many Stormtroopers might have
remained in the fight except for the fact that when injured or momentarily stunned, they fell down one of the many sheer drops that seem to be a common feature of Death Star architecture. The Death Star Health & Safety Unit, prior to its execution,
pointed out the folly of not providing either effective safety barriers or proper signage. It is our contention that this Health & Safety lapse also led to a security failure, preventing Death Star security personnel from carrying out their duties.

Destruction of the Death Star

The culmination of this chain of security failures eventually allowed the Alliance fleet to destroy the Death Star via the vulnerability inserted by Galen Erso. Identifying vulnerabilities in complex systems is notoriously difficult, and it is fair to
say that targeting the thermal exhaust port would have been a difficult attack to predict. However, Alliance analysts were able to determine that a direct hit on the exhaust port would be enough to cause a runaway chain reaction in the Death Star reactor
core. We can only conclude that the Death Star design team were subject to groupthink, and could not conceive of such an attack. To mitigate this, independent testing should have been used and might have identified the vulnerability early on.

Recommendation: Independent penetration testing to be carried out on Imperial systems.

This groupthink was evident in the relative ease with which Alliance fighters were able to carry out the attack. Death Star laser cannon were unable to engage X-Wing craft operating in close proximity to the station, and the catastrophe would have
occurred even sooner were it not for the (belated and ultimately futile) deployment of Imperial TIE fighters.

Recommendation: Future Death Star designs should include a risk modelling activity in order to better identify attack scenarios. This modelling should take into account the resources, motivation and ability of the attacker, as well as the probability of
the occurrence of the attack and its likely impact. Risks can then be mitigated, reduced or accepted in a managed way.

Finally, the reactor explosion, brought about by the strike on the thermal exhaust port, was the result of a runaway cascade of system failures. It is clear that the principle of defence in depth was not applied to the Death Star design. It is important
to realise that, given the right circumstances, any security measure will fail at some point. It is therefore crucial to put in place a layered set of measures, so that the failure of any particular measure can be mitigated by others. If such an approach
had been adopted for the Death Star, it is possible that the Erso vulnerability might not have been exploited to such devastating effect.

Recommendation: A layered approach to security be employed in all Imperial systems.

Conclusion

We can only conclude that security is not a serious concern of the Empire. It is apparent that security failures are both widespread and systemic. We therefore seek agreement from both the CEO (Lord Vader) and chair (the Emperor) to appoint a board level
executive, specifically responsible for Imperial security. This executive must have the resources to conduct a root and branch review of current practices, and the authority to ensure that corrective action is taken.

Recommendation: Appoint a board level security executive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)