Subscribe Now

* You will receive the latest news and updates on the Canadian IT marketplace.

Trending News

Blog Post

Five ways to reduce a data breach in 2016

Five ways to reduce a data breach in 2016 

One thing is clear: Information systems and the data they hold are being compromised at an alarming rate. Here are five ways to reduce the likelihood of your business suffering a data breach in 2016:

Make cybersecurity an executive responsibility

Cybersecurity, like other areas of corporate risk management, is a C-suite responsibility. While protecting company assets should be everyone’s job, too many businesses unfortunately view cybersecurity as a merely technical issue. IT and security professionals may be responsible for implementing and operating security controls, and it often becomes clear after a major security breach that they are well aware of vulnerabilities but did not have the budget and management support required to address the issue.

There have been many debates about which executive should be responsible for cybersecurity. Given the magnitude of risk involved, most companies should have a qualified Chief Security Officer (CSO) who reports directly to the CEO. The CSO’s responsibilities should include all aspects of security: physical, cyber, and personnel.

Some companies forgo the CSO role in favour of a security manager or placing operational cybersecurity in the hands of the IT department. This is generally a mistake. Firms without a CSO should formally add security risk management to the COO’s or CFO’s list of responsibilities. Some organizations have successfully placed cybersecurity responsibility into the CIOs hands, but the vast majority find combining the CIO and CSO role challenging due to competing priorities.

Teach IT and security professionals to speak business

Poor communication between executive management and security professionals is a constant source of frustration in many organizations. A common complaint among IT and security pros is that they are aware of potentially serious problems, but management “won’t listen” and fails to provide the resources necessary to fix them. After a major security breach, it is not uncommon for stories to surface suggesting that the technical vulnerabilities were known prior to the breach, but were not addressed.

It is easy to blame management. But a frequent root cause is that IT and security professionals fail to communicate with management in business terms. It is unrealistic to expect non-technical managers to understand the intricacies of cross-site scripting, buffer overflows, and cryptography. It is also not their job to do so. Security professionals have a responsibility to communicate cybersecurity risks in terms that the rest of the business can understand and can use to make better business decisions.

Assume everything is potentially hostile

The Internet as we know it is more than twenty years old, but developers continue to repeat the same mistakes. Perhaps the most frequent mistake is to assume, often implicitly, that people will act as expected. For example, web developers often assume that a browser will behave as intended, ignoring the fact that a malicious user may reverse engineer an applet or intercept and modify data between the browser and server.

It is common today to create an application that runs on a mobile device or in a browser, and a back-end server with which it communicates. It is human nature to assume that the application will behave in a predictable way when interacting with the server. However, hackers often reverse engineer applications and communication protocols. It is unsafe to place trust in any application running on a customer’s device, even if you wrote it.

When designing a network, system, or application the underlying assumption should be that everything is potentially hostile.

Look for low-hanging fruit

Exotic attack scenarios attract a lot of attention in security circles and in the media. But many successful attacks are remarkably unsophisticated. Organizations of all sizes need to focus on the basics and avoid being distracted by the latest shiny object: Pay attention to security architecture basics, and isolate critical systems. Consider every user’s PC, inside and outside the organization, as a potential source of attack. Harden every server. Ensure that logs are forwarded to a reasonably secure server.

In addition to attacks on web servers and APIs, the major corporate attack vectors remain email and the web. Financially motivated criminals look for external weaknesses, and failing that, they often target system administrators. Statistics favour the intruder; they can make a virtually unlimited number of attempts. All they need is one system administrator with one vulnerability on their PC to click one one malicious web link and they own a privileged account. Organizations that deal with payment cards and other financial transactions are especially vulnerable. In many cases putting a second PC on each administrator’s desk that is used solely for privileged administrative tasks would be a simple and highly effective security investment.

Address authentication issues

If there is one security project most companies should tackle in 2016 it is user authentication. Passwords have become the bane of existence for many corporate users, and weak authentication systems continue to be a major source of vulnerabilities. Most organizations torture users with increasingly strict password rules: chose a different complex passphrase for each application that a human can’t possibly remember, change it regularly, and don’t write it down. Then they lament about passwords on post-it-notes.

There are still some cases in which long complex passwords make sense (such as passphrases for encryption systems), but most organizations would do better to combine a more reasonable password with a second factor for sensitive applications or transactions. A good system will prevent sensitive authentication data (including passwords, even if salted and hashed) from being stolen, detect brute force attempts, and adapt authentication based on risk instead of a one-size-fits-all approach.

This is an area that deserves more attention, including from the open source community. Instead of each application providing its own custom authentication system, the emphasis should shift to creating and leveraging a solid authentication system across all applications.

Have a security question you’d like answered in a future column? Email

Related posts