In case there is a data breach, below is our organization's incident response plan
- Stop the breach
Once our organization notices a breach, it’s important to contain the breach as quickly as possible. Time is of the essence. We should start by isolating any system(s) accessed by the attacker so we can prevent the breach from spreading to the entire network. Disconnecting breached user accounts, if that was the attacker’s method can help, as can shutting down a specific department that was targeted.
Once it’s been contained, it’s important to eliminate the threat to prevent any further damage. Again, methods for eradication of the attack vary depending on the type of attack itself; it can be done by reformatting the affected assets and restoring them or blacklisting an IP address from where the attack originated.
- Assess the damage
Once the attack has been stopped and eliminated, the next step is to investigate it and assess the damage it has caused to our organization.
Knowing how the attack happened is needed to prevent future attackers from the same tactics and succeeding. Also, it’s important to investigate the affected systems so that any malware possibly left by the attacker can be detected. The assessment should include:
- What was the attack vector?
- Was the attack based on social-engineering tactics or through user accounts?
- How sensitive is the breached data?
- What is the type of that data affected?
- Does the data contain high-risk information?
- Was the data encrypted and can it be restored?
- Notify those affected
After the investigation, the next step is to notify authorities, third-party organizations and any individuals who might be affected. Since regulations govern the time frame in which the breach needs to be reported, it’s always best to do it as soon as possible. The notification can be distributed via email, mass email, phone calls or any other mediums of communication you typically use with the affected parties.
In the notification, organizations need to cite the date of the breach, what was compromised and what the recipient can do for protection from any further damage. This also allows the organization to maintain its integrity and save its reputation, combating the backlash that always accompanies data breaches.
- Security audit
After taking the first steps in recovering from a data breach, a security audit is needed to assess the organization’s current security systems and to help with preparation for future recovery plans.
Amazon AFN and MFN Orders
Most of our products are also sold on our Amazon Store, for orders placed on Amazon through our Amazon Store. Your information is protected under the Amazon Data Protection Policy, for the complete policy, please visit https://docs.developer.amazonservices.com/en_US/dev_guide/DG_DataProtectionPolicy.html
As defined by Amazon Data Protection Policy, "Personally Identifiable Information" ("PII") means information that can be used on its own or with other information to identify, contact, or locate an individual (e.g., Customer or Seller), or to identify an individual in context. This includes, but is not limited to, a Customer or Seller's name, address, e-mail address, phone number, gift message content, survey responses, payment details, purchases, cookies, digital fingerprint (e.g., browser, user device), IP Address, geo-location, or Internet-connected device product identifier.
When you make a purchase through our Amazon Store, the order information is passed into our ERP system. The following process detailed how we process/store/dispose your order information passed from Amazon MWS.
When exporting Amazon order information via Amazon MWS into our system, all our Amazon MWS data are stored on our Oracle NetSuite ERP with AES encryption, Our fulfillment team will only be accessing NetSuite via their 256-bit TLS encryption for accessing Oracle NetSuite ERP system through strong 128/256-bit SSL encryption with Role-Level Access and Idle Disconnect and IP Address Restrictions for extra security layers.
Our Oracle NetSuite ERP system only stores NON-Amazon-PII such as Order Number, Seller SKU, Unit Price, Quantity sold encrypted through NetSuite Encryption API. Amazon PII is only fetched in memory and not stored in our database. At the time when the fulfillment team is ready to print shipping labels, our Oracle NetSuite ERP will decrypt the Amazon Order ID and pass this information to our REST API which is hosted on Amazon AWS EC2 to obtain Amazon PII such as shipping address, then the API will generate the shipping label as PDF file and output the shipping label as memory stream to the designated Zebra printer.
Our ERP system does not store PII such as customer’s shipping address, so our fulfillment team does not have access to Amazon PII besides the actual physical shipping label. All the PII are disposed as soon as the shipping labels are processed and printed.
For Non-PII information such as Amazon Order ID, we store this information on our Oracle NetSuite ERP system by calling the NetSuite Encryption API via AES encryption method.