Asia Pasific Region Singapore, SG experiencing partial outage

ISO 27001 Clause 9.1 Require

Establishes two aspects to be monitored and measured.

Details of past management reviews with updated actions.

Any changes to internal and external issues that concern ISMS.

Feedback on any corrective actions, audit and measurement results.

We suggest you reed our information about Platform Security Policy.

If you want to participate to find vunerability of our platform, We recommend

you to read the following instruction on Vulnerability Disclosure Policy

and due to the sensitive nature of security information,

the Company provides an encrypted method (PGP) to report the issue.

WORLDWIDE FLUSING DNS DUE SWICTHING EMAIL NETWORK SERVER

Resolved
Operational
Started over 1 year ago Lasted about 6 hours

Affected

PLATFORM ACCESS
Platform Public Delivery Front-End
Platform Public Delivery Front-End Beta
Platform Private Access Front-End
Platform Private Access Back-End
Platform E-mail Server Front-End
Updates
  • Resolved
    Update

    SUMMARY ISO/IEC 27001:2018 Information Security Management System (ISMS)

    ISO/IEC 27001 is an international standard on how to manage information security. The standard was originally published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) in 2005 and then revised in 2013, the last version remain on 2018.

    ISO/IEC 27001 Audit Assessment Reports for the incident :

    Third Party Vendor - Trust Guard, LLC - Internal Document Report url: https://popitsnack.com/assets/files/iso27001/POPITSNACKTRUSTGUARDASS_ISO27001.pdf

  • Resolved
    Resolved

    Errors in Email portal and Indonesian Server Email Due DNS Propagation

    Incident Status : Degraded Performance

    Components Affect : Platfrom Email Server, Platform End-Points

    Locations : Indonesia

    Summary An IMS is key to a Company’s ability to effectively identify, respond to, and mitigate the impact of an incident, and enables providers to analyse and identify risks and trends to inform preventative measures. For the assigned roles when the incident declared, see the Timelines tab. For timeline feedback. To save time entering timeline events, use the quick action /timeline.

    Current Status [Resolved] No further occurrences of this error have been reported during our monitoring period. We consider this incident resolved and will continue to work with our provider for further analysis.

    THESE INCIDENT IMPACT AND RAISING UPDATES TO THE DOCUMENTS AND POLICIES

    • [ ] Security Commitment on https://popitsnack.com/documents/commitment-documents/security/

    • [ ] Commitment and Guarantee of User Data and Transaction Security on https://popitsnack.com/documents/commitment-documents/commitment-and-guarantee-of-user-data-and-transaction-security/

    Use the following links to create related issues to this incident if additional work needs to be completed after it is resolved:

    Corrective Action | Incident Review | Infra investigation | Confidential Support Contact | QA investigation

    Note : In some cases we need to redact information from public view. We only do this in a limited number of documented cases. This might include the summary, timeline or any other bits of information, laid out in out handbook page. Any of this confidential data will be in a linked issue, only visible internally. By default, all information we can share, will be public, in accordance to our transparency value.

  • Monitoring
    Monitoring

    Investigating Problem : Switching Email Server

    Identified Problem : To update the nameservers provided by us in domain DNS settings; after that, it will take up to 48-78 hours for complete propagation, that period which will take to complete the resolution of IP with the DNS record is considered as DNS propagation time.

    In technical terms, every ISP maintains a DNS cache, which stores the data of domain-level DNS records. When you update any new DNS record for the domain name, it has to be updated to the ISP so that the request will be served through the new record. Every ISP has a different TTL (Time To Live) period; depending on that, they refresh the DNS cache. DNS Server is handling this request. Some DNS servers will update the cache within 15 minutes, or some take up to 78 hours; hence, we as a host always recommend our customers wait up to 48-78 hours for the complete propagation.

    Solving Problem : Why does DNS propagation take too much time? DNS propagation delay can happen due to two reasons. Name server changes at your registrar. DNS caching due to TTL value set up in resource records. We have very little control over the first case as any changes done at the registrar may take 24 to 48 hours to propagate on Internet (though it’s generally nowhere near this long). We can manage the downtime of the site in the second case.

    To reduce the DNS lookup overhead, every name server cache the DNS records fetched at a time. The time for which these values remain in the cache is controlled by the TTL (Time to Live) value set in these resource records. For example, if the A record of the site has a TTL value, say 14400 seconds (4 hours), then this result will stay in the DNS cache for 4 hours once fetched from the authoritative name servers. If the IP address of this site is changed in between, the name server which caches the previous result will not be able to see this change as it is still fetching the details from its local cache.

    Affected Components : Major Platform Endpoint and E-mail communication

    Not-Affected Components : E-mail Notification communication