Are Applications and Devices Becoming More Secure from Hackers?

Thanks for the A2A, Anton D.C. Recently, a series of advancements in security standards and methodologies have been implemented to reduce the likelihood of security breaches by hackers. One of the key internationally recognized frameworks for evaluating IT security is the Common Criteria for Information Technology Security Evaluation (CC) and the companion Common Methodology for Information Technology Security Evaluation (CEM). These standards form the technical basis for the Common Criteria Recognition Arrangement (CCRA).

The Evolution of Security Evaluation Standards

The CCRA ensures that products are evaluated by competent and independent licensed laboratories to determine the fulfillment of particular security properties to a certain extent or assurance. Evaluation outcomes are documented in the Certified Products by Assurance Level and Certification Date list, which clearly shows a trend of more applications and devices achieving EAL (Evaluation Assurance Level) 6 and higher since 1999. This list reflects a tangible effort towards enhancing security standards.

User Preferences and Security Perception

Despite the advancements in security evaluation standards, modern users often do not demand that vendors provide software that has been more than functionally tested. In many cases, users are content with using open-source software, even though such software often comes with explicit disclaimers against fitness or merchantability. The use of insecure applications by untrained staff on untrusted networks can never be significantly enhanced in security terms. This situation perpetuates a critical security flaw, leaving users vulnerable to attacks.

Overview of Common Criteria Levels

The Common Criteria levels range from functionally tested to semiformally verified design and tested. Here is a very brief synopsis of each level:

Functionally tested: The software is tested solely from a functional perspective. Structurally tested: Beyond functionality, the software's structure is also tested. Methodically tested and checked: The software is tested and checked methodically. Methodically designed tested and reviewed: The software is designed, tested, and reviewed methodically. Semiformally designed and tested: The software is designed and tested semiformally. Semiformally verified design and tested: The software's design is verified semiformally and tested.

Most developers today have never worked on space or nuclear applications that require high Common Criteria levels, even at CCEAL 3. As a result, it's not uncommon for such developers to say, "It is impossible to have a program without bugs," which is a false statement.

The Perpetuation of Insecurity

The rush to market and the emphasis on functionality over ease-of-use/security have created a vast demand for insecure software. This environment has made it almost inevitable that hackers will always have victims. Additionally, the rampant usage of open-source software without appropriate modifications to ensure only relevant code and validated paths are introduced can result in fewer security assurances. For example, the Shellshock vulnerability was caused by including Bash in a server instead of the more secure Bourne shell. The inclusion of Bash allowed code paths that were not intended for memory access, violating the principle of least privilege. Poor design principles significantly contributed to this failing.

Conclusion

While security evaluations and standards such as the Common Criteria have made strides in enhancing security, the ongoing challenges of user perception, market pressures, and inadequate security practices continue to create vulnerabilities. It is crucial for developers, users, and vendors to understand and adhere to secure design principles and rigorous security evaluation methodologies to safeguard against hackers and ensure more secure applications and devices.