Security & CVD

1. Securitymodel

One-Home is ontworpen als hybride local-first platform. De woninglogica blijft waar mogelijk lokaal, terwijl One-Home Cloud functies levert die centraal voordeel hebben. Dit beperkt de impact van een internetstoring en verkleint de hoeveelheid woningdata die standaard naar cloud hoeft.

2. Technische beveiligingsprincipes

De huidige architectuur bevat of voorziet onder meer de volgende maatregelen:

• unieke installatie-identiteit met een cryptografische device-key;
• ondertekende device requests met timestamp/nonce-controles om replay te bemoeilijken;
• gescheiden signing voor licentie-/entitlementinformatie en releasegegevens;
• beveiligde browser-/accountsessies met CSRF-bescherming;
• 2FA voor gevoelige beheerfuncties;
• lokaal versleutelde cloudback-ups voordat de inhoud wordt geüpload;
• tijdgebonden en expliciete toestemming voor ondersteunde remote diagnostiek;
• auditinformatie rondom relevante beheer- en updateacties.

Concrete implementatie kan per release veranderen. Securityclaims op deze pagina zijn daarom architectuur-/productclaims, geen garantie dat software absoluut onkwetsbaar is.

3. Updates en software supply chain

Officiële updates horen te worden aangeboden met integriteitscontrole en ondertekende release-informatie. De updater is ontworpen om een nieuwe versie eerst te bouwen/starten, healthchecks uit te voeren en waar mogelijk terug te rollen wanneer de nieuwe installatie niet gezond wordt.

Voor productie horen dependency monitoring, SBOM/dependency-inventarisatie, secrets-management, gecontroleerde build/releaseprocedures en periodieke securitytests onderdeel te zijn van het onderhoudsproces.

4. Back-up- en herstelbeveiliging

Cloudback-ups zijn ontworpen om vóór upload lokaal te worden versleuteld. Recovery keys en lokale secrets moeten buiten publieke repositories, logs en supporttickets blijven. Herstelprocedures horen regelmatig getest te worden.

Een versleutelde back-up is alleen nuttig wanneer zowel de back-up als de benodigde herstelgegevens beschikbaar zijn. Bewaar recovery-informatie daarom gescheiden en veilig.

5. Coordinated Vulnerability Disclosure — scope

We nodigen beveiligingsonderzoekers uit om technische kwetsbaarheden op een verantwoorde manier te melden. De volgende onderdelen zijn in beginsel in scope wanneer ze aantoonbaar door One-Home worden beheerd:

• one-home.online en officiële One-Home subdomeinen;
• Mijn One-Home en het officiële Admin Portal;
• One-Home Cloud API’s;
• officiële One-Home Core releasepakketten die door One-Home zijn gepubliceerd.

Diensten, hardware, accounts en infrastructuur van derden zijn niet automatisch in scope. Test geen systemen waarvan je niet redelijkerwijs kunt vaststellen dat ze door One-Home worden beheerd.

6. Regels voor verantwoord onderzoek

Bij beveiligingsonderzoek vragen we je om:

• alleen je eigen account, installatie of expliciet toegestane testomgeving te gebruiken;
• niet verder te gaan dan nodig is om het bestaan en de impact van een kwetsbaarheid aannemelijk te maken;
• geen persoonsgegevens van anderen te downloaden, wijzigen, verwijderen of publiceren;
• geen denial-of-service, massale scanning, spam, social engineering of fysieke aanvallen uit te voeren;
• geen wachtwoorden, tokens, private keys, recovery keys of andere geheimen publiek te maken;
• de kwetsbaarheid eerst vertrouwelijk aan One-Home te melden en redelijke tijd voor onderzoek en herstel te geven;
• bewijs veilig te bewaren en na afronding te verwijderen wanneer dat niet meer nodig is.

7. Hoe meld je een kwetsbaarheid?

Gebruik tijdens early access de contactmogelijkheid op one-home.online en begin de eerste regel van je bericht met SECURITY. Deel in het eerste bericht geen wachtwoorden, private keys, recovery keys of grote datasets. We kunnen daarna een geschikt beveiligd kanaal afspreken wanneer gevoelige technische details nodig zijn.

Neem in een goede melding op:

• het getroffen domein, endpoint, release of component;
• een heldere beschrijving van de kwetsbaarheid en verwachte impact;
• minimale reproduceerbare stappen of een proof-of-concept;
• eventuele relevante request/response-informatie, zorgvuldig ontdaan van geheimen;
• een veilige manier waarop we je kunnen bereiken.

8. Wat kun je van ons verwachten?

We streven ernaar een serieuze securitymelding binnen 5 werkdagen te bevestigen en daarna periodiek terugkoppeling te geven zolang het onderzoek loopt. De werkelijke oplostijd hangt af van ernst, complexiteit, benodigde afhankelijkheden en de mogelijkheid om veilig te testen.

We vragen onderzoekers om publicatie te coördineren totdat een redelijke herstelperiode is verstreken. Een eventuele publieke erkenning of beloning is niet automatisch en wordt alleen aangeboden wanneer dat afzonderlijk wordt afgesproken.

9. Onderzoek te goeder trouw

Wanneer je je redelijkerwijs aan dit beleid houdt, te goeder trouw handelt en schade probeert te voorkomen, is het onze bedoeling om je melding als verantwoord beveiligingsonderzoek te behandelen en niet als misbruik van onze meldprocedure. Dit is geen algemene juridische vrijwaring en kan geen rechten van derden of dwingende wetgeving opzijzetten.

10. Buiten scope

Voorbeelden die normaal niet als securitykwetsbaarheid worden behandeld: ontbrekende securityheaders zonder aantoonbare impact, self-XSS zonder realistische aanvalsketen, klikjacking op pagina’s zonder gevoelige acties, puur theoretische issues zonder reproduceerbare impact, rate-limit meldingen die alleen met onrealistisch verkeer aantoonbaar zijn en problemen in producten van derden die niet door One-Home worden beheerd.

Als je twijfelt of iets in scope is, meld het liever met minimale informatie dan actief verder te testen op data of systemen van anderen.

11. Beveiligingsincidenten

Een operationeel securityproces hoort procedures te bevatten voor detectie, triage, containment, herstel, logging en communicatie. Wanneer een incident persoonsgegevens raakt, wordt beoordeeld welke meld- of informatieverplichtingen onder de AVG of andere toepasselijke wetgeving gelden.

12. Productie-hardening

Voor een commerciële productie-release zijn onder meer onafhankelijke security review/penetratietest, dependency- en secrets-scanning, veilige sleutelrotatie, databasehardening, restore-tests, monitoring en een uitgewerkt incident-responseproces onderdeel van de aanbevolen releasecriteria.

13. Securitycontact en security.txt

Het standaardbestand /.well-known/security.txt verwijst naar deze policy. Vóór brede publieke/commerciële lancering wordt daarnaast een dedicated beveiligd securitycontact (bijvoorbeeld een gemonitord security-adres en optioneel een encryptiesleutel) ingericht.