When is a laboratory needed?
An information security laboratory is needed where an error in selection or implementation costs a business a lot: the purchase of information security has already been agreed upon, but it is not clear how the product will fit into the existing network; the team is planning SIEM/SOAR, but the sources of events are scattered; you need to implement CIPF, DLP, PAM, WAF, end device protection or AppSec tools, and the customer’s architecture is more complex than a typical demo.
This page is for CISOs, CIOs, information security architects, infrastructure teams, DevSecOps, CII, GIS and ISPDn owners, as well as for procurement, who need to justify the choice of solution not with marketing slides, but with a proven scenario, restrictions, implementation requirements and acceptance criteria.
What solutions are we checking?
Perimeter and network
NGFW, WAF, AntiDDoS, VPN/CIPF, segmentation, DMZ, secure access, DNS/TLS, logging and SOC integrations.
Workstations and servers
Endpoint security, EDR/XDR, trusted boot, device control, server security, agent architecture and performance impact.
access rights and privileges
IDM/IAM, PAM, MFA, service accounts, roles, access lifecycle, rights review and control of administrative actions.
Data and Applications
DLP, DBF/DAM, Masking, Tokenization, AppSec, SAST/DAST/SCA, WAF for Web/API and Secure Test Loop Validation.
SOC and response
SIEM, SOAR, SGRC, NDR, TIP, UEBA, event sources, correlation rules, response scenarios and transfer of tasks to ITSM.
AI and adjustable environments
Secure AI services, RAG, LLM, request logs, access roles, CII, GIS, ISPDn, threat model and operational requirements.
Key Terms, Plainly Explained
| Term | Decoding | What does this mean in the laboratory? |
|---|---|---|
| SZI | Information security tool. | A product or set of measures that is intended to protect a system, data, network, application or users in a particular architecture. |
| CIPF | A means of cryptographic information protection. | VPN, crypto gateways, HSM, PKI and other solutions where certificates, keys, regulations and compatibility with the infrastructure are important. |
| SIEM / SOAR / SGRC | Collection and correlation of events; response automation; risk management, controls and reporting. | The laboratory tests event sources, log quality, response scenarios, task routing and management reporting. |
| EDR / XDR / NDR | Endpoint detection and response, advanced correlation, and network discovery. | Visibility of attack techniques, noise, load on infrastructure, integration with SOC and ease of investigation are checked. |
| WAF / NGFW | Web application protection and next-generation network firewall. | Rules, exceptions, impact on applications, false positives, and relationships with logging are checked. |
| PAM / IDM / IAM | Manage privileged access, user identity and rights. | Roles, administrative scripts, service accounts, access coordination and auditing of actions are checked. |
| DLP / DBF / DAM | Leak control, database protection and data activity monitoring. | Policies, data sources, impact on business processes, masking and evidence of events are checked. |
| HLD / LLD | High-Level Design - top-level architecture; Low-Level Design - detailed project. | The laboratory helps validate architectural solutions before they are included in the industrial design and procurement specification. |
| PoC/pilot/UAT | Proof of Concept - hypothesis testing; pilot - limited implementation; UAT - User Acceptance. | Each format should have a purpose, test scenarios, success criteria, limitations, and a decision on the next step. |
How does the laboratory cycle work?
Hypothesis
We fix the business problem, outline, restrictions, regulations, data, owners, success criteria and conditions under which a pilot is considered useful.
Stand
We collect a test or limited production environment: network, roles, logs, test data, integrations, policies and secure test scripts.
Scenarios
We check not only “is it installed or not”, but real working situations: attacks, false positives, fault tolerance, rights, reports and load.
Restrictions
We document where the product requires improvements to the architecture, licenses, agents, logs, exceptions, performance, or the participation of another team.
Solution
We are preparing a conclusion: implement, change the architecture, expand the pilot, choose another class of solution, transfer to procurement or postpone the project.
World practices and Russian context
The lab approach is similar to how mature organizations manage cyber risk: first test the applicability of controls, then scale. RESTART uses as guidelines NIST Cybersecurity Framework 2.0 for the risk management framework, CIS Controls for practical protective measures, MITRE ATT&CK Enterprise to describe attacking techniques and OWASP Web Security Testing Guide to test web/API environments.
In the Russian context, the laboratory is especially useful for ISPDn and Federal Law No. 152-FZ, CII and Federal Law No. 187-FZ, GIS, FSTEC requirements, threat models, certified information protection system and cryptographic information protection system. It helps to understand in advance what measures actually work in the customer’s architecture, what documents and logs are needed for acceptance, and where changes to HLD/LLD, regulations or the operational model are required.
How AI helps the laboratory
AI should not independently decide on the choice of information security, admission to industrial implementation, or risk acceptability. But he is useful as an engineering assistant: he helps prepare test scripts, parse logs, map requirements and controls, group pilot results, find recurring constraints and assemble a draft report for CISO, CIO, procurement and technical teams.
For RESTART, it is important that the AI works in a secure environment: with approved sources, access roles, logging, human verification and a ban on transferring private data to external services without approval.
What does the customer get?
| Artifact | How it helps business |
|---|---|
| Pilot protocol | Shows what was tested, on what data, under what conditions, and what conclusions can be used to make a decision. |
| Compatibility Matrix | Links the product to the network, directories, logs, applications, agents, databases, SOC, ITSM and customer constraints. |
| Acceptance Criteria | They help procurement, information security and IT agree on what is considered a successful implementation and what needs improvement. |
| Operation risks | Load, noise, false positives, lack of logs, agent conflict, performance and support issues are identified in advance. |
| Requirements for HLD/LLD | Transform laboratory results into architectural solutions, integration schemes, rules, regulations and technical specifications for implementation. |
| Road map | Captures the next step: implementation, delivery, pilot expansion, architecture change, training, or abandonment of an unsuitable option. |
Where RESTART Adds Value
The value of RESTART is not simply to turn on the demo stand. We connect the laboratory with a licensed information security practice, partner ecosystem, HLD/LLD, supply of information security/information security information, implementation, integrations and post-launch support. The customer receives not a one-time demonstration of the product, but a verifiable route from the hypothesis to the production environment.
Deliverables
- description of the business problem, pilot boundaries and success criteria;
- diagram of the stand, integrations, data sources, roles and logging;
- a list of tested scenarios, limitations, risks and dependencies;
- compatibility matrix with current infrastructure and regulatory requirements;
- recommendations for HLD/LLD, purchasing specifications, licenses and operation;
- roadmap for implementation, expansion of a pilot, or abandonment of an unsuitable solution.
First practical step
A rational start is a short laboratory session for 5-10 working days: define the environment, select one or two critical scenarios, assemble a minimal stand, check compatibility and prepare a decision on the next step. For regulated environments, this stage is better associated with CII/Federal Law No. 152-FZ diagnostics, HLD/LLD design or IS audit.
Frequently asked questions
How is a laboratory different from a vendor demo?
The demo shows the capabilities of the product in a convenient environment. The laboratory checks how the solution works in the customer's architecture: with its roles, logs, integrations, restrictions, regulations and operational requirements.
Is it possible to pilot without combat data?
Yes. For most scenarios, you can use test data, masking, limited samples, synthetic events, and secure accounts. If real data is needed, the legal basis, access roles and restrictions are fixed in advance.
When is a pilot needed, and when is an architectural review enough?
If the solution affects the network, agents, logs, performance, access rights, or regulated data, a pilot is usually more useful. If the risk is primarily related to the design principles of the loop, you can start with HLD/LLD validation.
Can the results be used for procurement?
Yes. The pilot protocol, acceptance criteria, compatibility matrix and list of restrictions help justify the choice, clarify the specification, licenses, implementation requirements and support conditions.
How is the laboratory connected with CII, Federal Law No. 152-FZ and GIS?
For regulated loops, the laboratory helps verify the applicability of protection measures before industrial implementation: logs, roles, information security/information protection information, threat model, documents, acceptance and evidence of compliance with requirements.
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.
