Immune System
Technologists do have systems for diagnosing and treating software "diseases" at a global scale. I'm not talking about installing anti-virus on your laptop. I mean something on par with the WHO or CDC for computers. There are technical institutions that take the lead in identifying, squelching, fixing, and tracking software vulnerabilities. The most notable institutions are the MITRE quasi-government corporation and the SANS Institute, the infamous Open Software Foundation (OSF); yet the public's probably heard of none of these institutions. (See IEEE resources on cybersecurity). The public only hears about are the hacks themselves, and the typical mantra of "change your password" and "install anti-virus"! Technologists should be our own advocates when it comes to best practices in actually securing legitimat, online use. MITRE, for example, maintains the list of known malware but has only a limited capacity for informing the mass public about avoidance measures. Technologists merely use their "disease coding" system (called CVE) much like doctors and insurers use to identify and catalog malware. Technology can have more "doctors" and "vaccinations" for these malwares and we've made progress on getting cures out to prevent computer infections, such as integrating automated update and patching solutions. The biggest producers of consumer software -- Microsoft, Apple, and Google -- (can) push these vaccinations to our laptops, smartphones, and tablets.
What technologists do not have is a computer immune system. This is a critical need because anything online is under constant attack. Securing technology has shifted from reactive to proactive because of the increased risks with the Internet of Things (IoT). We seldom implement automated security systems that are on par with our more robust, biological immune systems. Technologists might install some "skin" in the form of a firewall that protects the outer shell of technology, and we probably install a baby's "newborn white cells" in the form of immature anti-virus scanners, and hopefully we will throw in a basic "diary" that logs a glimpse of what computers are exposed to, but we don't implement mature, robust IT security. This immature, computer immune bandaid is the reason websites are still hacked, your pictures stolen, and fraudulent purchases appear on your credits cards. Technologists, however, have the potential to be more effective than human doctors in treating this disease.
Security (Mis)persception
As constant consumers of technology, we can be more informed and educated about modern IT security needs. IT security had been, in my experience, the purview of computer networking teams instead of application or DevOps teams. The upside to a preoccupation with network security is a relatively better defense at the lower levels of the OSI model, including the risks from physical access and operation. The immunity gap is at the upper OSI layers where online applications sit. I've been watching the MITRE/SANS reports on software security, in addition to the OSVDB (Open Software Vulnerability DataBase) and noticed these reports mimic some of the headlines of hacks. Dangerous file uploads, session hijackings, SQL injection -- these headlines are in the top computer software "diseases". OSVDB's trends upto 2014 give a quick view of vulnerabilities that mimic those listed in the MITRE/SANs report of 2011 (which itself changed little from the 2010 and 2009 reports). This indicates to me that application vulnerabilities are a primary culprit in modern, IT insecurity. Also, an analysis of software libraries in 2012 indicated that the increasing dependency on programming frameworks further exacerbates the "infection" beyond your own code or operating container. When I subscribe to a security fix mailing list for one those big producers of consumer software, I notice a lot of libraries showing up that are dependencies of services and application containers. So the elephant in the room is technologist's and consumer's (mis)perception of what is most at risk for modern technology.
I went back to the catalog of software vulnerabilities and reduced the CVE type lists to just the Top 10 "Cures" that will change our perceptions of security risks. The list is devoid of what technologists typically discuss during security debates: denying remote access (via network firewalls), difficult passwords that rotate (via password policies), anti-virus scanning, etc. Nada. Instead, these vulnerabilities are found in higher layers of the OSI model, like the application itself or application server:
- use DB frameworks and static queries, do not make direct SQL calls or dynamic queries
- use jailboxes and programmatic interfaces, do not call the system directly
- validate all data input and verify buffers at build time, do not assume you'll get normal stuff
- do force document encoding and compliance, do not assume you'll get normal documents
- use authentication and authorization frameworks including roles, do not flatten or hard code credentials
- same as #5; mandatory access controls that deny everything by default are tedious and the most secure
- same as #6, do not embed passwords in code or configuration
- do use data encryption libraries, do not assume authentication or authorization will secure privacy
- same as #3 including file MIME type too, do not assume you'll get a normal file
- do favor stateless sessions and verify state changes, do not trust stateful user sessions
Behavior Change
As I release my next application, I'm going to try a White Hat approach with due diligence. Some tools to use during development are cross-referencing MITRE's mitigations and the above guideline Cures to see how often these vulnerabilities appear while I'm coding. Here's the full MITRE/SANS List 2014:
| Rank | Score | ID | Name |
|---|---|---|---|
| [1] | 93.8 | CWE-89 | Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') |
| [2] | 83.3 | CWE-78 | Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') |
| [3] | 79.0 | CWE-120 | Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') |
| [4] | 77.7 | CWE-79 | Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') |
| [5] | 76.9 | CWE-306 | Missing Authentication for Critical Function |
| [6] | 76.8 | CWE-862 | Missing Authorization |
| [7] | 75.0 | CWE-798 | Use of Hard-coded Credentials |
| [8] | 75.0 | CWE-311 | Missing Encryption of Sensitive Data |
| [9] | 74.0 | CWE-434 | Unrestricted Upload of File with Dangerous Type |
| [10] | 73.8 | CWE-807 | Reliance on Untrusted Inputs in a Security Decision |
| [11] | 73.1 | CWE-250 | Execution with Unnecessary Privileges |
| [12] | 70.1 | CWE-352 | Cross-Site Request Forgery (CSRF) |
| [13] | 69.3 | CWE-22 | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') |
| [14] | 68.5 | CWE-494 | Download of Code Without Integrity Check |
| [15] | 67.8 | CWE-863 | Incorrect Authorization |
| [16] | 66.0 | CWE-829 | Inclusion of Functionality from Untrusted Control Sphere |
| [17] | 65.5 | CWE-732 | Incorrect Permission Assignment for Critical Resource |
| [18] | 64.6 | CWE-676 | Use of Potentially Dangerous Function |
| [19] | 64.1 | CWE-327 | Use of a Broken or Risky Cryptographic Algorithm |
| [20] | 62.4 | CWE-131 | Incorrect Calculation of Buffer Size |
| [21] | 61.5 | CWE-307 | Improper Restriction of Excessive Authentication Attempts |
| [22] | 61.1 | CWE-601 | URL Redirection to Untrusted Site ('Open Redirect') |
| [23] | 61.0 | CWE-134 | Uncontrolled Format String |
| [24] | 60.3 | CWE-190 | Integer Overflow or Wraparound |
| [25] | 59.9 | CWE-759 | Use of a One-Way Hash without a Salt |
No comments:
Post a Comment