I recently read an article about cybersecurity and concluded that vendor influence on the discipline has reached a point of concern. Vendors and their marketing campaigns strive to introduce different terms into cyberprofessionals’ occupational jargon to appear unique. This creates confusion when speaking to other professionals about the industry and detracts from efforts to normalize protection strategies across technologies within the enterprise. Such chaos can be even more frustrating than when vendors dismiss computer security to justify their cybersecurity product that does what an existing computer product does, or should do.
Computer security is defined as the protection of the operating system (OS) or internal operating system (IOS), its configuration, buffering and miscellaneous files, and the underlying hardware and associated logic. This includes at rest, in transit and during execution.
Yes, the OS and configuration files are information and could be considered part of information security. However, doing so would imply that user data and system data are equal, and that is simply not true. Most OSs and IOSs used today suffer from user infliction. This occurs when users perform an unsafe act and the results affect the OS/IOS—and, thus, everyone on the computer. It is difficult to understand why this is so. But inexplicably, cybersecurity experts go about their day discussing how to augment the OS/IOS with third-party software (e.g., virus protection and intrusion detection) without considering why the operating system allows this to occur. Understanding memory management and protected memory is just as important as knowing what is happening to information when it is at rest in a file system. If the OS/IOS allows configurations only while allowing user tasks to run in a controlled and protected area of memory, how could that user not affect another user if their task failed or was malicious? As a side note, I should qualify that most mainframe computers are exempt from this discussion. These computers tend to treat users as untrustworthy, so they are isolated as much as possible.
Another issue that I have encountered is that many do not understand what a computer is or where it exists. Much like cell phones are really radios in a culture of misnomers, so are computers. Computers exist as servers, workstations, routers, switches and other computational devices. They may perform a specific function, but, ultimately, they are computing devices with IOSs or OSs. Configuring these devices has become a matter of information security. However, because vendors choose to minimally protect themselves, users have been given the ability to determine if their OSs/IOSs are protected or not.
Many authors discuss the fact that default values in computers are the main attack vectors for hacking. I admit when I used to conduct white-hat penetration testing, that was my first approach. This includes hoping for default passwords (which is not hacking—it is taking advantage of the least fortunate). If the default values provided adequate protection, many attacks could be stopped. For example, the OS has files to which no user needs access. Out of the box, these files should be protected. Such is the case for third-party products. In addition, privilege is not a yes-or-no condition. OSs/IOSs should have a hierarchy of privilege so that no third party or user task runs at the same level of privilege as the OS/IOS.
The reality is that there has not been a concerted effort to improve the security of most OSs/IOSs within computing devices. Although we are unlikely to experience a shift back to embracing computer security, the following are some tips for improvement:
- All settings configurations provided by a specific device should be set to deny all. As a cybersecurity professional with the help of your vendors, you should make the decision of what connects to what and who can get to what. Access and privilege should be a function of your organization, not the vendor’s default configuration of device. Please change all default passwords.
- Only a fool uses a tool they do not understand. Proprietary algorithms and undisclosed product features prevent you from understanding your own protection strategy. Push for nondisclosure agreements (NDAs) and other means to understand exactly what a product does. In addition, prior to purchasing, be sure to learn how the vendor wants to compromise the secure state of an OS/IOS in order for the system to run.
- Defense in depth (DiD) is a multidimensional concept. Not only should there be layers of perimeters, but diversity should exist in protection mechanisms. This ensures that if a single product fails, the organization is not compromised across the entire infrastructure. Be wary of the “increase training excuse.” If you have 2 similar products from 2 different vendors, it should be easy to normalize what they are doing against each other. Note that you should be cautious, as many security products cannot coexist on the same device in which they want the same location in memory to run. Additionally, if you have a deep learning product that performs dynamic training in the operational environment, you may want to ask yourself how you know it is still in a secure state. It could be attacked, providing it thousands of fake attack vectors to increase false positives. After a while, it would be ignored, and then the real attacks would start.
- Software developers, especially Unix programmers, tend to write code that is entirely privileged. This deems it unnecessary to form a good understanding of OS protections. Instead of a single piece of code being privileged for a given time period (i.e., privilege blocking), the entire product is privileged all the time. It also means that when a user runs a privileged program, if the code were to fail, it could result in an unsecure state, making privilege available to the user. Many attacks occur like this. Ultimately, you want to minimize privilege as much as possible.
- Do not assume that a vendor—even one that provides a cybersecurity product—is well versed in computer security. They understand deadlines and their particular application. Having been a software developer, I can attest that many things get missed intentionally or unintentionally in the last week before a deadline. The departments responsible for missed deadlines are often those that oversee cybersecurity testing, functional testing and configuration management. Perhaps that is because they serve as gatekeepers to the operational environment and are the last to touch the software. Early adoption can often mean early risk.
Third-party software purchases will continue to be made in an effort to augment the shortcoming of the operating systems and the unaware user action. Until we admit that each class of user has a different need for access and privilege, this binary perception of privileged and nonprivileged will remain the standard.
Bruce R. Wilkins, CISA, CRISC, CISM, CGEIT, CISSP, is the chief executive officer of TWM Associates Inc. In this capacity, Wilkins provides his customers with secure engineering solutions for innovative technology and cost-reducing approaches to existing security programs.