Secure Infrastructure

secure infrastructure

Secure Infrastructure

Company Y initially approached Hexegic having outgrown their initial startup-orientated IT infrastructure. The nature of their business exposes them to specific threats that they were concerned were not adequately mitigated; they also had significant availability, resilience and scalability concerns. They asked us to provide guidance and recommendations for an infrastructure that allows these risks to be managed effectively.

Referring to the standard lifecycle, Hexegic initiated the assessment phase via several teleconferences. These were attended by Hexegic’s Head Consultant and Senior Network Engineer as well as the IT team and senior board members from Company Y. Hexegic needed to understand the current system architecture and services as well as the required services they wanted to introduce in a newer system. We also needed to understand the current and future threats, and where the existing service didn’t meet the expectations of the senior board members.

Company Y employ developers and analysts. The former tended to circumvent security controls that they considered unnecessary or unduly onerous. The latter target malicious actors on the dark/deep web and so need routine access to hostile parts of the Internet. The nature of Company Y's work means that they will be actively targeted by these actors. Company Y had a clear understanding of their risks but were aware that their infrastructure did not facilitate their management. Company Y also had aggressive growth plans that would exacerbate the problems with their current infrastructure.


Following this assessment phase, we produced several high-level designs for infrastructures that gave Company Y greater visibility and control of users, network traffic and applications, had improved internal and external defences and provided protective monitoring functionality. We covered on-premise, co-located and cloud options.

The intent of the communication phase was to explain these high-level approaches to the board to enable them to select one for more detailed work. The Head Consultant delivered the approaches via a presentation to and discussions with the Company Y board. We chose this approach because board members have a technical background and so readily understood the implications of each approach without needing the level of explanation that we would normally include in a longer report. The discussion format was appropriate because it supported the board’s need to balance the costs and benefits of each approach.

During the understand phase of the standard lifecycle we elaborated the selected approach (co-location with some cloud services). This followed design principles that Hexegic have applied in accredited infrastructures delivered for government and the defence sectors that we adapted where appropriate to mitigate Company Y’s particular risks. This included a fully managed infrastructure service, highly segregated internal infrastructure, centralised management functions, ongoing vulnerability assessments, patch management and configuration management activity.

data center

The final phase of the consulting part of the engagement (Evolve in the standard lifecycle) involved deploying and testing the new infrastructure, progressively migrating users onto it and decommissioning obsolete parts of the old infrastructure. Following sign-off by the Company Y's board we achieved this over a five-month period. The infrastructure has accommodated expansion into the USA and Europe, an upgraded isolated browsing solution and new development services.

Secure Firmware Builds

Company X were concerned about the integrity of their firmware build infrastructure and processes. Compromising the build infrastructure, its inputs (source code, third-party binaries etc.) or its outputs would lead to their appliances executing compromised firmware images. They proposed air-gapping this infrastructure in a dedicated secure room, with import of source files and export of firmware images via removable media. They approached us to review their proposal.

Following our standard lifecycle, we initiated an assessment phase via a teleconference involving the Head Consultant and a domain expert from Hexegic, and firmware development and infrastructure leads from Company X. Our intent here was to understand the threats and business drivers behind their integrity concerns. An understanding of those risks then drives solution architecture: we can’t comment upon a proposed solution without understanding the requirement, and in a security context we can’t assess mitigations without understanding the risks that they purport to target.


To communicate our analysis to the customer we produced a short report, drafted by the domain expert and reviewed and approved by the Head Consultant before release to the customer. The report:

  • Defined the security requirements.
  • Listed the identified threats.
  • Discussed the attack surface, including source code integrity, third-party artifacts, access control, personnel security, physical infrastructure, build systems/networks/tools/processes, and the process for transferring the firmware image to the hardware appliances.
  • Assessed the proposed solution in the context of the above analysis.
  • Covered possible defences and alternatives to the proposed solution.

The understand phase of the lifecycle consisted of follow-up discussions with Company X once they had reviewed the report. They decided not to pursue their original proposal as it would not deliver the intended security properties. The situation continues to evolve: the threat remains; Company X have a better understanding of defences and their costs and benefits, and are currently considering the appropriate justifiable level of investment.