FiDo (FiDo) is a charity. FiDo is planning to move to offices in Coventry. As part of the move, they are planning to implement a better security architecture and network design. This is in comparison to their current arrangement which has evolved haphazardly over the last three decades.
FiDo currently has a workforce of approximately 1300 individuals. A significant proportion of these workers are unsalaried volunteers. Most work predominantly online with a few days each month in the office.
There are several departments including HR, Finance, Corporate Comms and System Administration.
FiDo works closely with a New Zealand collaborator organisation on a range of projects.
FiDo has all its online assets within the domain fido22.cyber.test
.
FiDo needs the proposed security architecture and network design to accommodate significant expansion over the next three years.
The FiDo foundation charter requires them to utilise open-source solutions where these exist. Currently and for the foreseeable future, they adopt a Debian by default operating system on all endpoints and infrastructure.
We have been engaged as a Security Architect and Network Design consultant by FiDo. We have been supplied with a starter pack. This starter pack comprises:
- a preliminary infrastructure layout that summarises what FiDo believe to be the main components of their infrastructural needs. This utilises the historic IP address block
80.64.0.0/16
that they inherited from the original creator of the organisation in 1988. - a preliminary emulation of this infrastructure. This deliberately incorporates negligible security architecture and summarises many bulk features (user endpoints for example) into a small number of representative examples.
- Re-design the infrastructure to group assets into zones of trust. As well as re-organising existing assets, you should identify and position any infrastructure assets that you believe should be present but are missing. Similarly, you should remove any assets that are present but not appropriate.
- Implement the reconfigured zones of trust as LANs or VLANs within the Netkit realisation. Insofar as is reasonable, you should utilise what is provided in the starter pack with the minimum essential change.
- Re-organise the IP address utilisation of the organisation so as to reduce to a realistic minimum, the number of public IP addresses that FiDo should retain from within the
80.64.0.0/16
address block. Utilise NAT and / or port-forwarding as appropriate. - Implement the re-organised IP address allocation and associated routing within the Netkit realisation.
- Determine the filters that should apply between zones of trust (network firewalls) and where significant on endpoints (host firewalls).
- Implement the filters within the emulated infrastructure.
- Verify that connectivity is achieved between appropriate clients and the services they should be able to utilise.
- Verify that connectivity is prevented between inappropriate clients and the services they should not be able to access.
- Design, implement / configure and test additional features that will usefully enhance the organisation's security posture. You should select features that you consider to be particularly important to FiDo and that will also showcase your comprehensive mastery of security architecture and network defence, above and beyond what you have already demonstrated in tasks 3.1 to 3.4 above.
To achieve a mark up to 55% you must:
- use the specified file names,
- define and implement credible zones of trust. As a minimum, you should have four: untrusted public internet; internet-facing servers; staff workstations; internal-facing servers,
- define and implement re-organised IP addressing, using the specified private addresses internally.
- implement NAT so that client devices on private IP addresses can interact with services provided on the public internet,
- define and implement filters between zones of trust,
- partially verify that connectivity is achieved / prevented as appropriate between clients and services,
- have hashes at the demonstration that match the hashes in the submission nccd-hashes.sha1 file (ie provide evidence that nothing significant has changed between the submission and the demonstration).