WIUNIX / SECURITY
Security at Wiunix.
Our approach to access, protected systems, controlled changes and responsible security communication.
PRACTICES AND BOUNDARIES
Controls must remain useful in day-to-day operations.
Our public security approach focuses on reducing unnecessary exposure, limiting privilege, protecting secrets and making important changes traceable. Recovery readiness and useful evidence belong alongside prevention. These are engineering principles, not a claim that every product has identical controls or that incidents cannot happen.
01 / ACCESS
Access and identity
Separate human and service access. Scope permissions to the required task, keep administrative paths bounded and make ownership clear. Access decisions should be traceable to the responsible role rather than relying on broad shared privileges.
02 / CONFIGURATION
Protected configuration and secrets
Reduce unnecessary services, risky defaults and exposed management surfaces. Keep passwords, tokens and keys outside public source and ordinary diagnostic records. Handling sensitive access is a separate controlled activity.
03 / TRUST BOUNDARIES
Network boundaries
Make trust zones, ingress, egress and administrative paths explicit. A connection between systems should have a defined purpose and scope; connectivity alone does not imply trust or permission to act.
Defined purpose
Named owner
Bounded scope
A permitted connection has a purpose, an owner and a defined scope.
POLICIES WITH A PURPOSE
Make the boundary understandable.
Review who or what needs access, which service it needs and why the connection is permitted. A policy should be assessed against its intended task, with its administrative path and owner clear.
REQUEST
↓
→
POLICY
↓
→
SERVICE
The Aegis and cloud-firewall views are illustrative concepts. Supported controls and availability follow the relevant product documentation and agreement.
Explore WIUNIX Aegis →
DETECTION AND FOLLOW-UP
Evidence with a purpose
Use relevant operational signals to qualify an incident and support technical follow-up. Diagnostic material should be bounded and avoid unnecessary secrets or personal content. Collection and retention requirements depend on the product and agreed context.
01
Event
What happened and when.
02
Context
Which service and permission were involved.
03
Owner
Who reviews the observation and follows it up.
CHANGE AND RECOVERY
Treat a security change as an operating change.
Review risky changes, preserve a usable rollback path and verify the resulting behavior. A restriction that unexpectedly stops a required service is an operational problem to investigate, not proof of stronger security. The change needs a clear scope and evidence of its intended effect.
Recovery is part of resilience
Consider backup, restore and service recovery together with access and hardening. Recovery instructions, responsible roles and the relevant verification steps must fit the system. A backup file or a monitoring signal alone is not proof that a service can be restored.
How We Work →SCOPE
VERIFY
ROLLBACK
REPORT A SECURITY CONCERN
Start with a concise, non-sensitive report.
If you believe a Wiunix public site or product has a security issue, use the existing contact page to identify the affected product or URL and provide a high-level description. State that the message concerns security so the appropriate follow-up can be arranged.
Useful information
✓
Affected public URL or product and version, if known.
✓
A short description of the behavior and potential impact.
✓
When you observed it and a way to contact you.
✓
A redacted outline of reproduction steps, using your own authorized environment.
Protect people and systems while reporting
Do not include passwords, keys, tokens, personal records, account contents or full unredacted logs in the public form. Describe the issue first; arrange a suitable channel before sharing sensitive technical evidence.
A report is not permission to test systems, access another person’s data, disrupt service or expand exploitation. Avoid further access if you encounter information that is not yours, and describe the observation without redistributing that information. Coordinate disclosure through the contact conversation.
No response-time commitment, bounty, legal safe harbor or authorization for security testing is established by this page. Product-specific terms and separately agreed responsibilities continue to apply.
Principles are not certifications
We do not claim a certification, independent audit result, universal protection or guaranteed incident outcome without supporting evidence. Product behavior, supported controls and current limitations should be assessed in the relevant product documentation and agreement.
Looking for help with your own environment?
The Cybersecurity service describes client assessment and engineering work. This page explains Wiunix’s public approach and reporting route. Privacy information and service conditions have their own notices.
Cybersecurity services →Privacy notice →Terms of use →