How to prevent a data breach

The recent data breach at Optus exposed 9.8 million customer records to the risk of identity theft. It has once again drawn attention (albeit unwanted) to the corporate responsibility (or lack thereof) of protecting their customer’s personal identifying data.

Governments in many countries have enacted legislation to make reporting data breaches mandatory so that at least the company’s customers know when their details have been breached. Governments have also enacted Privacy Legislation to protect a customer’s personally identifiable information further.

The Australian Government is actively talking about increasing penalties for companies where customer data is exposed as part of a cyber-attack. If the legislation is amended, the organisation will pay a hefty fine for a data breach.

The onus for preventing data breaches is now firmly with an organisation. It is no longer acceptable to approach security risks with a ‘laissez-faire’ attitude that ‘it won’t happen to us’.

Cyber-attacks are reported across social media and news outlets, especially phishing campaigns. The population is being informed as a countermeasure to educate people about recognising suspicious emails and phishing attacks, thus limiting the potential impact.

Companies must take security seriously, and the good news is that this is a significant change from 15 years ago, when security testing was a ‘we’ll do it if we have time’ activity. System architects and software engineers are responsible for ensuring that they architect and build a secure system. Quality Assurance teams are committed to ensuring that the system is ‘fit for purpose’. This means that its security requirements have been implemented and remain secure under varying conditions, such as denial of service attacks.

When thinking about the security of a system or application, the following steps should be followed:

Follow network security standards to ensure security across your infrastructure’s physical, technical, and administrative layers.

If your system uses a privileges-based approach to granting different access levels to user groups. Thoroughly testing these privilege-based systems is a critical quality risk as this approach usually controls access to personal information.

Design your system to use 2-factor authentication methods such as One Time Pin (OTP), mobile device authenticators, and Biometric data.

Ensure passwords meet specific strength criteria, i.e., must contain Upper- and Lower-case letters, special characters, and numbers and be at least X characters long.

Any system exposed to the outside world, especially web-based applications, should perform penetration testing.

Customer data privacy is a first-class citizen; therefore, how you use this data MUST comply with all current privacy legislation. e.g., Any personally identifiable data copied from production must be obfuscated/masked or encrypted depending on what the system’s data needs are.

Many company users must manage multiple passwords, especially system admins. These users should employ password vaults where encrypted passwords are stored and can only be accessed using a decryption key.

These files should never contain the usernames and passwords in plain text. The secrets must be encoded or use technologies like AWS Secrets Manager.

The OWASP initiative contains a list of application security risks, called the OWASP Top 10, that should be examined and included in the application architecture and design. Software Testing must ensure that the overall test strategy includes mitigations for these risks if they apply to your application design.

This informs the governance and management strategies and should roll down into the procedures followed by your network and application development teams. While it’s easy to ‘pooh bar’ the need for organisational policies, the thinking and intent is the most critical outcome as they inform operational procedures that direct teams’ behaviours and characteristics.

Phishing scams are becoming increasingly sophisticated. Providing your staff with the ability to identify them is critical. Letting your customers know as soon as you become aware that customers are being targeted, communicate with them that they need to be mindful of a circulating phishing email. Using social media platforms can quickly let your customers know about phishing scams.

The mitigation of security risks must be front and centre of any test strategy or approach. Regardless of the development methodology, the critical outcome is not the document but the thinking that identified the security risks and then devised the activities that would mitigate these security risks.

We constantly hear about building quality in, but we don’t hear teams talk about ‘architecting and designing security in’. You cannot bolt security or quality onto an application as an afterthought. There are enough ‘Frankenstein systems’ created from bolting on one system after another resulting in significantly increased complexity.

The impact of building complex systems is:

• Increased security and quality risks;
• Reduction in the resilience of a system due to the introduction of multiple failure points;
• The ballooning in the cost of testing due to increased environmental complexity, reliance on third-party test systems, and advanced data dependencies across systems;
• Your teams need the increased knowledge to understand the independent system behavior and the complete end-to-end data and user journeys.

Very little consideration is given to the security requirements, or even less consideration is given to how it’s going to be tested. The latter is frequently the cause of bad decisions regarding test data usage and sourcing. This can lead to data leakage from the test system, or worse, the test system is vulnerable to cyber-attack because the word ‘test’ means it doesn’t need anywhere near the same level of security as production.

Test Data is one of the most significant privacy challenges we face as it needs to come from production data sources, and this test data can be the source of data leaks. For example, the test system emails clients because the email addresses were not masked, customers or random people get SMS messages because the mobile phone numbers are not masked, or the masking creates legitimate phone numbers.

This makes it more critical than ever to:

1. Ensure security policies exist that drive governance and management of security risks.

2. Ensure all data at rest is encrypted.

3. The organisation has data tools readily available that support the data masking, obfuscation, and encryption of customer data that all teams can access.

4. Ensure security is architected and designed into the solution, such as using OWASP best practices for website development.

5. Revise authentication methods to utilise 2-factor authentication.

6. Use development tools that statically review the code for known security patterns for the development language being used or dynamic tools that test for known security vulnerabilities.

7. Ensure test strategies and approaches have security risks and their mitigation covered.

8. Educate employees in:

• The requirements of the privacy act;
• Recognizing and handling phishing and suspicious emails.

9. Enable staff to manage multiple passwords using password security management software.

Simply accepting the security risk because a project or business doesn’t have the budget is no longer justifiable. From the start, the cost of ‘building security in’ is significantly less than trying to plug a collapsing dam wall that’s now flooding thousands of people.

A recent AFR article highlights that this thinking still exists, ‘You can’t just flick a switch: small business fears new data laws‘. But a small business could cost-effectively address its security needs by:

1. Assessing their security needs based on 12 points raised under “So what can we do” and overlaying their business portfolio and user expectations.

2. Identifying the existing gaps in their current infrastructure and applications against the requirements.

3. Creating a list of issues that are classified using a three-by-three matrix that maps the level of exposure and the impact if it occurred.

Luvo Testing has been involved with many projects where the security topics discussed above should have been on everyone’s radar early in the project development lifecycle. Stakeholders must understand the risks and what activities must be performed to mitigate these risks. Customers entrust their data with companies, so it must be secured at all costs.