Cybercriminals target corporations with high-value assets to steal data, expose infrastructure vulnerabilities, and to ruin customer confidence. The average cost of a data breach, according to the Cost of a Data Breach Report 2021 by IBM Security, is $161 ($146 in 2020) per record. And the average total cost of a data breach in 2021 is $4.24 million, up from $3.86 million in 2020. The costs of fighting cybercrime, restoring data and services following a breach, lost revenue, and reputation damage are increasing. Some industries, such as healthcare, financial institutions, and pharmaceutical companies are hit hardest by cybercrime and its costs. The healthcare industry’s cybercrimes costs rose 29.5 percent from 2020 to 2021.
Lost business accounts for the largest portion of cybercrime costs to businesses at 38 percent of the $4.24 million. Detection and escalation is responsible for 29 percent of that number, post-breach response comes in at 27 percent, and notification finishes last at 6 percent. Lost business costs include reputation damage, customer turnover, and system downtime.
In this article, we look at data security, software data security, and application security which includes an overview of some preventative and proactive measures that businesses can take against cybercrime.
Some businesses thrive on data. They ingest it, manipulate it, create reports from it, while others create data for others to use. And for some businesses, the data they create is their intellectual property. Cybercriminals who want to steal, sell, or simply expose data seek out high-value data such as personally identifiable information (PII), which can be sold to other cybercriminals to commit identity theft, to defraud credit card companies, or to directly steal from victim’s bank accounts. Data security is imperative for those who collect, create, or work with data, especially data that includes PII or financial information.
Data has three basic states, which are data in-flight, in-transit, and at rest*. These areas are where data is vulnerable to attack, clandestine capture, and corruption. All need to be dealt with from a security point-of-view to ensure integrity, safety, and confidentiality.
Data that is in-flight is data that is being transferred over a network of some sort. That network can be wired or wireless from a source such as an end user or a remote device. It is active data that is being sent and collected, such as a customer entering their information into a product purchase order form. It could be environmental data being wirelessly transferred to a data collector from a remote weather station. It can also be data collected by a cybercriminal from a skimmer device at a bank where victims enter their account information via an automatic teller machine to withdraw cash.
For in-flight data the solution to man-in-the-middle, network sniffing, or other live data stream capture techniques, is to encrypt the data during transmission from the source to the destination. With strong encryption, AES-256 for example, the data is unusable to cybercriminals because they would need the decryption key to read it.
Data that is in-transit is data that is in the process of moving between systems, disks, networks, or other devices for backup, disaster recovery (DR), archival purposes, or disposal. Generally, data in-transit has been compressed, deduplicated, or prepared for archive. Two very common methods of preparation before transfer is to zip or to tar and then compress into a package or tarball for easier transmission.
All data should be encrypted prior to transmission from one location to another. Encrypting these packages or tarballs ensures that they cannot be unarchived and read even if they’re disrupted or captured between their sources and their destinations. It’s highly recommended that all packaged data be encrypted using AES-256 encryption before moving between any two locations.
Data at rest is also vulnerable to attack and exfiltration by cybercriminals. Data at rest means that data is in a stored state on disk, on tape, or inside a database. There are multiple methods of encrypting data at rest but the method used should be capable of AES-256 encryption.
Cybercriminals are persistent, can remain silent or near silent for months, and can slowly exfiltrate data at levels that often operate below alert thresholds but they can’t break strong encryption such as AES-256, at least not in the foreseeable future. Data at all stages and states must be encrypted from source to target to disposal. No single security measure can thwart every attack or criminal. Security requires constant vigilance and a layered approach on every endpoint. In the next section, the discussion turns to software security.
Software security is a very broad topic that ranges from standalone software applications to client and server applications on both ends of a client/server system to complex N-tier applications, operating systems, platforms, and infrastructures. The variety and inconsistency in all aspects of these systems make security extremely complex. Look at the list of devices, software, and platforms that businesses of any size might have to deal with.
- Mobile devices with a variety of operating systems
- Desktop, laptop, and Tablet computers with a variety of operating systems and peripherals
- Virtualization technology
- Server systems using Linux, Unix, and Windows
- Multiple hardware platforms and vendor solutions
- IoT devices from different vendors
- Routers, switches, and WiFi devices
- Camera systems
- PBX systems
- Cloud solutions
You can easily see from this list that even a small organization’s security quickly becomes a complex issue. For proprietary systems, you have no control over fixes, patches, security risks, or update frequency.
Add into this mix your own in-house developed software and you have quite the security list on your hands. In the next section, I cover application security for applications that you develop in-house and have full software development life cycle (SDLC) control over.
There are multiple locations along the continuous integration and continuous deployment (CI/CD) pipeline (Figure 1) where application security testing can occur. The farther to the left one can test code, the earlier in the process one can detect and remediate code security flaws.
The two methods of testing code early in the integration and delivery process are software composition analysis (SCA) and static application security testing (SAST). They examine uncompiled code for security vulnerabilities. Combining these two vulnerability testing methods early in the pipeline can alleviate many code flaws that lead to insecure applications that result in breaches from attacks such as injection, leaks, overflows, and cross-site scripting.
Early detection and remediation helps alleviate the possibility of including known vulnerabilities such as those described in OWASP’s Top Ten Web Application Security Risks, CWE Top 25 Most Dangerous Software Weaknesses, and Common Vulnerabilities and Exposures (CVEs).
SCA testing scans your code for occurrences of open source software (OSS) which might include vulnerabilities. These scans also help you resolve any licensing issues when using code snippets from OSS applications.
SAST combined with SCA allows developers to test and fix code early when it’s less expensive and less problematic to do so. SAST scans for weaknesses without executing the code and prevents code flaws from flowing into production where they become application vulnerabilities.
Scanning and remediating code early in the development process doesn’t remove the need for late stage or post-production testing, but it removes obvious and known code flaws from being baked into applications prior to deployment.
Internet-facing web applications and their backend components, including stored and moving data, are under constant scan, probe, and attack from cybercriminals, therefore a layered approach to security is necessary. Web applications can be scanned for code flaws and remediated early in the development process by applying the powerful combination of SCA and SAST. By using this “left side” testing and remediation process, developers can be more confident in releasing code to production. However, continuous vigilance and testing is still required on production applications to scan and remediate new vulnerabilities.
* Some sources define these states differently.