Whilst we were writing about the cost of Free Wi-Fi, USA telecommunications giant Verizon announce a data breach from June. The security lapse will affect six million customers who have call in to customer services in the last six months. An insecure Amazon Web Services S3 storage server allowed anyone with the web address to download the data.
Verizon claims no data has been stolen or lost, but in a statement to Buzzfeed, said “…[they] regret the incident and apologize to our customers…“. Verizon went on to say the “…leaked dataset included the information of approximately 6 million subscribers.”
Cybersecurity firm UpGuard discovered the problem, but how long could this have gone on for if they hadn’t? It was misconfiguration as a result of human error that left the storage solution vulnerable. Verizon’s Israel-based customer service facility, NICE systems, was the source of the security-lapse. However, this does illustrate the need for tighter management of third-party suppliers and the need for GDPR here in the UK.
Contents of the exposed data is what is most troubling though. Security PINs used to verify identity of customers were stored in plain text alongside telephone numbers. If a hacker were to convince a customer service agent they’re the account holder, they’d be able to gain access accounts.
With this access, a hacker could receive security messages from Verizon and change the login credentials. Then with access to the account they could revoke the real customer’s access! To protect your Verizon account you should update your security PIN. Use the situation, if you are a Verizon customer, to update your security PIN – it’s just good practice.
Worried about the security of your Amazon S3 data?
There are a number of built-in security mechanics within AWS to prevent unauthorised or unintended exposure of your data. Following the five security steps for your AWS root (master) account is a good first port of call.
By default, all S3 buckets are private from the world. You need to open up public access before anyone can read the data contained within. We use Amazon’s S3, we love S3. However, you must consider the following to tighten security:
- Use a bucket-policy when access is required to an entire bucket. All traffic that doesn’t meet a predetermined condition can be explicitly denied. Customers using Cloudfront can leverage signed URLs to prevent global read access.
- Access Control Lists and Identity Access Management are useful to allow access to files within buckets. Access can be controlled to be from the AWS console only, programmatically (through code) only or both.
- Turn on logging so you can see who has accessed what data in your bucket and when
- Test unauthorised access – if a resource shouldn’t be available by directly accessing the URL, try it out in your browser. Security misconfiguration becomes obvious because with proper configuration you would expect to see an Access Denied message.
Human error is the biggest contributing factor in most data breach situations. Prepare to accept the consequences of situational arrogance if you fail to monitor your people and process. Routine checks on access controls, data security and processes is key to avoiding the headlines.