Why “it’s clear” is more expensive than the project
The project stage is the first thing that is crossed out from an information security project under deadline pressure. The logic is clear: security measures have been chosen, the vendor is known, the engineers are experienced - why spend a month on documents. The bill comes later and in other items: the wrong license was purchased, the firewall did not break because the traffic pattern turned out to be different, the migration required downtime, which no one agreed upon, and at the acceptance it turned out that there was nothing to check for compliance - there are no requirements in a measurable form.
HLD and LLD solve one problem: translate intent into verifiable solutions before they are paid for. This is not bureaucracy, but a way to detect an error at a stage where fixing it costs editing the document, and not postponing the release.
Boundary between HLD and LLD
Confusion between documents leads to the fact that HLD is inflated to settings, and LLD remains a set of pictures. The division is based on one criterion: HLD answers “what and why”, LLD answers “how exactly”.
| Aspect | HLD (High Level Project) | LLD (low level project) |
|---|---|---|
| Question | What architecture covers threats and requirements? | How it is assembled and configured |
| Reader | CISO, architect, procurement, regulator | Implementation and Operation Engineer |
| Network layer | Segments, trust zones, flows between them | VLAN, addressing, routes, filtering rules |
| Protective equipment | Classes of funds and rationale for choice | Models, versions, licenses, connection diagrams |
| Fault tolerance | Required mode and allowed downtime | Clusters, synchronization, switching order |
| Access | Role model and principles of differentiation | Groups, policies, specific rights |
| Result | Agreed architecture and specification for procurement | A document from which the system can be assembled and reproduced |
Practical consequence: HLD cannot be implemented, and LLD cannot be debated about the architecture. Trying to make do with just one document gives either an unfulfilled plan or settings without justification.
What should be in HLD
- System boundaries and protected objects. What exactly do we protect: information systems, segments, data, their categories. Without this, it is impossible to assess the sufficiency of measures. The starting point is inventory; for CII it is mandatory and is discussed separately in the material about inventory.
- Model of threats and intruders. Not a formal extract from the methodology, but applied to your environment: which scenarios are real, what measures cover them, what risks are taken consciously.
- Requirements. Regulatory (FSTEC, FSB, industry), contractual and internal - summarized in a list, where each requirement has a solution that solves it. This will also become the basis of the acceptance testing program.
- Architecture. Zones, flows, control points, places where protection equipment is activated, control and monitoring scheme.
- Justification for choosing a class of funds. Why an application-level firewall and not an intrusion detection system; why a cryptographic protection tool of this particular class. For certified solutions, the required protection class and the availability of a valid certificate.
- Non-functional requirements. Bandwidth, latency, number of sessions, event storage depth, availability mode. The most common source of implementation failure is their absence.
- Specification. List for purchases with licenses, support and deadlines. The error here pops up months later, when it’s too late to buy more.
What should be in LLD
- Connection schemes each tool: in a gap, mirroring, agent - indicating interfaces, addresses and ports.
- Address plan and filtering rules in a form that can be transferred to configuration, rather than as a description of intent.
- Configurations and Policies: verification profiles, correlation rules, access policies, integration with the catalog and monitoring system.
- Deployment and migration order: sequence of steps, work windows, state of services at each step, criteria for moving to the next.
- Rollback plan. What to do if the service is unavailable after switching. The absence of this section is the cause of most nightly incidents during implementation.
- Test program and methodology: requirement being checked, steps, expected result. The work is accepted based on it, and the regulator then checks it based on it.
- Operating procedures: update, configuration backup, failure actions, vendor support contacts.
Typical failures and their roots
| What happened during implementation | What was missing from the project? |
|---|---|
| The protection device does not support the load during rush hour | Non-functional requirements and performance calculations in HLD |
| The purchased license is not enough for the actual number of nodes | Specifications verified against inventory |
| Implementation required unplanned downtime | Migration order and agreed work windows in LLD |
| The system is assembled, but it is impossible to accept it | Requirements in measurable form and test programs |
| The tool works, but the events go nowhere | Schemes for integration with monitoring and event formats |
| After the contractor leaves, the system cannot be maintained | Operating procedures and reproducible configurations |
| The regulator requires justification for measures, but there is none | Connections “threat → demand → measure → evidence” |
Project as the basis for procurement and acceptance
HLD and LLD are not just engineering documents. They solve two commercial problems.
Purchase. The specification from HLD allows you to compare offers on the merits, and not on the final amount: you can see what is included in the delivery, what licenses are needed, what will need to be purchased in a year. We supply certified protective equipment and CIPF as part of the solution "Supply of information security equipment"; transfer of CIPF requires an FSB license - RESTART has it (more details).
Acceptance. The test program, which grows from a list of requirements, turns acceptance from a dispute into a procedure: each requirement is either verified or explicitly transferred. This is also the basis for subsequent regulatory checks - evidence is collected in advance, and is not restored retroactively.
Then the project moves into implementation - "Implementation of information security", and the network part is detailed in network security and perimeter protection.
When a project is required by regulation
- Significant CII objects. Creating a security system for a significant facility in accordance with Federal Law No. 187-FZ involves design with justification of measures and subsequent acceptance - see. "Protection of CII / Federal Law No. 187-FZ".
- Personal data information systems. The choice of protection measures is based on a certain level of security and threat model; without documents it is impossible to construct a justification for measures - “Federal Law No. 152-FZ and personal data”.
- State information systems. The security class and the composition of measures are fixed at the design stage - "GIS protection".
- Works under license from FSTEC. Design of protective equipment is a licensed activity; licensed practice RESTART is described in the decision Regulatory Compliance and Information Systems Protection.
HLD and LLD quality checklist
HLD
- Protection objects and system boundaries are listed and checked against the inventory.
- Each requirement is associated with a measure, each measure with a justification.
- There are non-functional requirements with numbers, not adjectives.
- For certified products, the required class is indicated and the availability of a valid certificate is verified.
- The specification covers licenses, support and term; verified with the actual number of nodes and users.
- The risks taken are clearly listed and signed by someone.
LLD
- According to the document, an outside engineer can assemble the system without clarifying questions.
- The interfaces, addresses, ports and connection diagrams for each tool are indicated.
- The migration order is broken down into steps with migration criteria and a rollback plan.
- There is a test program covering the list of requirements from the HLD.
- It describes where events go and how the system is maintained after delivery.
- Configurations are stored in a reproducible form, and not just in the memory of the implementer.
How RESTART does it
Our design stage is a separate solution "Design of information protection equipment / HLD and LLD". Logic of work: examination and comprehensive IS audit → threat model and list of requirements → HLD with justification and specification → LLD with configurations, migration and test program → implementation and acceptance according to the same program.
The selection of specific products is based on partner and vendor ecosystem, and complex solutions are tested on the bench Information Security Laboratories before the purchase, not after.
We need to analyze a specific environment - write to us.
Let's discuss your environment
Describe the task, current systems, constraints, and expected results. We will offer a practical first step: diagnostics, pilot, audit, roadmap or project team.
