http://freedompenguin.com/articles/opinion/how-big-is-your-target
In his 2014 TED presentation Cory Doctorow compares an open system of development to the scientific method and credits the methods for bringing mankind out of the dark ages. Tim Berners-Lee has a very credible claim to patent the technology that runs the internet, but instead has championed for its open development. This open development has launched us forward into a brave new world. Nearly one third of all internet traffic rides on just one openly developed project. Its place of dominance may be unsure as we approach a world with cybersecurity headlines. Those headlines do much to feed the industry of fear resulting in government efforts to close doors on open source efforts.
This paper is a qualitative theoretical discussion regarding cyber security and open source solutions written in three parts. Its goal is to demonstrate that the use of open source technologies reduces vulnerability to cyber attacks. The first part of this paper identifies the difficulties in presenting a software consideration model capable of illustrating the full spectrum of expectations for the performance of today’s code. Previous models merely address basic requirements for execution namely security, functionality & usability. While these aspects are important they fail to take into account modern requirements for maintenance, scalability, price, reliability and accessibility of software. This part of the paper modernizes the model developed by Andrew Waite and presents a clear model for software discussion.
Part two of the paper reviews the open source development model with particular care to illustrate how security considerations are taken into account. A large portion of this section is drawn from a first hand source with over two decades working with open source technology.
Part three looks at potential applications for the open source model of development in regards to Target’s 2013 breach and OpenSSL’s Heartbleed vulnerability. It illustrates how the application of open source solutions could be used to close the security holes that lead to Target’s breach and how the open source development model contributed to patching Heartbleed in quick order.
To illustrate the difficulty of finding a good model we can look at the 2013 Gartner Magic Quadrant for Social Software. This quadrant shows Microsoft as an industry leader, Google as a visionary, and VMware as a challenger. The chart completely ignored the actual social software that dominated 2013, Facebook. So while this is what Gartner’s business audience saw, the public saw thousands of youtube videos and websites that walk readers through best practices on how to use facebook as a social platform for business. Gartner’s chart is more in line with the ongoing conversation they’ve built up with their audience over the years and the consulting work they also perform. Beyond discussing it as a potential model, its narrow focus doesn’t make it useful for our purposes in this paper mostly due to the format constraints inherited by the two axis model.
Since Gartner’s model for software doesn’t fit this discussion on software considerations we’ll instead be using an updated version of Andrew Waite’s triad published on infosec in 2010 (Figure 1). In his triad he identifies Security, Usability, and Functionality as the key components of software that must be kept in balance for it to be successful. He specifically wanted to show how “an increase or decrease in any one of the factors will have an impact on the presence of the other two.” Each of these components are crucial in the design and implementation of modern software. Ease of use determines adoption and satisfaction. Functionality determines how useful the software is from a systems standpoint providing real value to the larger production chain of the industry employment of the software. Security is a major requirement for today’s software requirements as vulnerabilities cost companies millions in revenue if exploited. The need for securing the information kept digital in our society is so real that it has prompted the creation of the cyber insurance industry.
To
explain the interrelated nature of these areas Andrew writes, “as an
example, increasing the amount of functionality in an application will
also increase the surface area that a malicious user can attack when
attempting to find an exploitable weakness.” One can also see how
increasing the security of a product can greatly affect its usability
and functionality. If the software is so secure no one can use it, then
it becomes less useful because it becomes less of an asset to the
production line and the employee’s time. This triad does a very good job
illustrating the balance between each of the components listed. While
his 2010 model is certainly applicable, it is a static view of software
in a single snapshot of time. In order to expand the software beyond a
single instance we must add software maintainability as a dimension.
Over the past few years we’ve seen security issues in the press due to a lack of software maintenance. This emphasis on maintenance is one of the reasons for inspiring the TechSNAP podcast who’s motto early on was “patch your [explicative].” Software maintenance is a major part of cyber security. Sony’s massive 2011 breach was attributed to running outdated software and the U.S. Navy is still paying Microsoft millions of dollars to maintain Windows XP even though its end of life occurred nearly two years ago. A popular article on programmingisterrible.com discusses that each line of code contains a cost of
maintenance
over time. So, while Andrew Waite’s triad holds true for 2010, in 2016
we’ve learned the importance in both cost to business and customer need
for software that can be maintained in the long term. Projects are still
learning and refining their own particular processes for code
maintenance. In Android Google has learned to move more features to apps
that can be updated through the app store. OwnCloud which powers the
redundancy of CERN’s large data stores recently updated their software
to include fragmentation of certain features to make code maintenance easier.
While the above illustrates the need to patch for security issues, the process of patching is a separate component and it’s given a lot of attention in the IT field. Often IT personnel don’t patch due to risk of loss functionality. This is a secondary effect of the maintenance dimensions. This reluctance to patch increases the life cycle of vulnerability exploits. General code improvement is a separate requirement that affects security, usability and functionality. Conversely if code is hard to maintain, than its usability, functionality and security suffer. Because of this additional dimension, I’ve updated Waite’s model illustrated as Figure 2 of this paper. In this illustration we still maintain the interrelated aspects of the earlier work and the need for project managers to strike a balance with each aspect early on.
I reached out to Rix Ryskamp owner of Transcend Products LLC and inventor of U.S. Patent 20090232295 A1 (apparatus, system, and method for automated call initiation) for a review of this chart and he informed me that he applies an additional four criteria for software consideration within his organization namely, scalability, reliability, accessibility, and price. These additional aspects do make the model more complex, but by adding these additional dimensions from someone who not only purchases software to run his business, but also innovates within the space is worth consideration. Now instead of simply focussing on the code we have added dimensions that impact business operations not just code implementation. Due to space requirements I will not directly discuss the interoperability of these each of these additional dimensions beyond saying that price, scalability, and reliability impact whether a particular technology is adopted. Increasing or decreasing these impacts all other dimensions. Increased emphasis on functionality and usability directly impacts the amount of work required and increases the price. Increased emphasis on scalability impacts the larger security and maintainability footprints.
Although
this model has yet to be accepted formally by any particular
organization it seems to be intuitively used for nearly every adoption
of software. Case studies published by major corporations often speak in
these terms. While this paper’s primary purpose is to argue that the
use of open source technologies reduces one’s vulnerabilities to cyber
attacks no discussion on the subject can occur without understanding the
multiple considerations of any software project as they are all
interrelated.
We began this discussion in part one to find a model that can be used to facilitate a conversation for software. We reviewed Gartner’s model and noticed its limitations for our conversation due to it being tailored for a specific audience. Andrew Waite’s 2010 triad was functional but a rather static model that didn’t account to changes in software over time. After modifying Waite’s model to include the software’s lifetime we adjusted the model further to include principles of consideration used in business practices by a leader in the field. Now at the conclusion of part one we have a useful model for discussing software that we can reference looking at the adaptability and adoption of software.
Some producers in this marketplace are motivated to share their precompiled lines of code with others. Other producers are motivated to guard their code and restrict access to its human readable content through legal means. The code that is accessible for review is known as open source code and the counterpoint on the other end of the spectrum is closed source. It’s best to view these as philosophies connected on a spectrum. Excluding the two extremes the discussion on closed vs open source differences are better geared for a legal discussion, not a technical one.
Just as there are varying degrees of open and closed source options there are also varying production models for developing and publishing software. To ensure the software is meeting the right combination of items on the software considerations model from part one, some type of review process must exist. The most crucial group of stakeholders are the users themselves. As Eric Raymond stated in his book, The Cathedral & The Bazaar, “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.”
There are various models that leverage ongoing user feedback as part of software development, one popularly described today is the agile approach to software development. Kendall and Kendall describe the agile approach as being based on four values “communication, simplicity, feedback and courage” while adding that the developmental process is both “interactive and incremental.” Agile absorbs user feedback at multiple opportunities during development. The Systems Development Life Cycle (SDLC) is another model for software development that exists with greater structure than the agile method. In contrast to the agile method the SDLC has more limited user engagements during the developmental process but is still a very effective way to produce deliverable code.
Both agile and the SDLC have internal processes for review and development. While agile is better suited for teams with more flattened hierarchies it still requires a review process before publication. This review process is one of the most significant differences between open and closed sourced software. In a closed source development model the review process is built upon a limited population base. In an open source development model the review process’ population base can cover a broader slice of individuals. Both models use feedback to maximize the balance of the software considerations model.
The closed source development model could include a greater quantity and quality of programmers and participants than an open source one, but due to its closed nature it is difficult to capture accurate information to do a quantitative and qualitative comparison. Both development models leverage public input. Apple heavily enforces its very restrictive non-disclosure agreement with regards to development, but still releases public betas of their software to registered participants. Google, Microsoft and code other companies have similar practices to gather feedback from early adopters. While the closed source model does leverage public input it does so towards the end of a closed development cycle, and the testing does not generally include an audit of the code (Android Open Source Project is an exception to this).
In contrast the open source model leverages public input and audit very early on in the process. Ubuntu, a Debian based Linux distribution, has a regular release cycle named after the month and year of the release. Just hours after its 15.10 release, the daily .iso for 16.04 was already available for download. Early reviewers help to change the direction of the code and fix mistakes early on in the process. Martin Wimpress is the lead developer for Ubuntu MATE one of the top twenty Linux distritubtions searched for on DistroWatch.com. Martin explained the power that early user feedback has on his project. In an interview he discussed how one of his contributors is very conscious of shell script injection vulnerabilities. Martin describes how the general MATE developers are mindful of security but it’s not one of the things they have at the forefront of their mind when writing code. He goes onto explain how this contributor regularly files bug reports as the MATE team posts patches and updates which unknowingly contain script injection vulnerabilities. While this example illustrates the effort on the security portion of the software consideration model in open source other aspects receive similar attention. As mentioned earlier the octagonal shaped consideration model is rather intuitive to those in the industry. Chris Fisher has been reviewing open source software as part of his nearly eight year podcast, The Linux Action Show. Listeners of his reviews on the KDE and Gnome desktops will often hear him discuss many of the segments of this consideration model.
The contrast between open and closed source is worth some consideration. Martin Wimpress also described how his development process compares with its closed source alternatives:
While a close sourced model has limitations due to its unknown development, simply being open source doesn’t equate to greater security. Several open source projects don’t have the user base necessary to attract the level of technical users capable of submitting bug reports and contributing code. In some cases projects that do have a substantial user base but don’t have a system for integrating the feedback will also fail to adjust. Other open source projects, such as Linux Mint, just make questionable security choices. Again Martin Wimpress offered a succinct summation during our interview, “open source projects are more secure when there’s a peer review process in place” and the open nature of development allows that peer review process to be scrutinized for its effectiveness. In open source the ecosystem can be evaluated while in a closed model the ecosystem is largely unknown.
Reconnaissance was done in part through a Microsoft case study and although the links have been been removed from Microsoft’s website the PDF can still be downloaded from Microsoft.com. The case study specifies the hardware and software running throughout the network, the size of the network and hints at methods for remote updating. To nefarious actors the case study contains a good starting point to justify a malicious operation. It outlines the shape of a future attack. All the software considerations discussed in part one apply to both malicious and legitimate applications. Starting a project like this has an associated cost of finances and time. Functional software must be accessible and scalable in order to justify the cost of the breach with its associated risk of getting caught. Even mal-actors conduct cost benefit analysis and in this case the reconnaissance helped paint the picture of the amount and type of work required to pull off the heist.
While there are similarly large publicly shared open source companies that publish case studies such as Red Hat, most projects in the open source community don’t have the funding or need to advertise their products to attract customers. While Red Hat does publish case studies to attract customers the code generally speaks for itself. Red Hat is one player in an ecosystem that includes SUSE, Ubuntu and FreeBSD. Kris Moore, project manager for PCBSD, as recently as January reminded his audience of BSD’s slogan to “shut up and code.” While a novel saying, it’s evidence that the open source community in general is more concerned about what you write and how well it performs than writing case studies about it to attract new users. Linux has similarly relied upon the experience of users and word of mouth with users emphasising different aspects of the software consideration model. Linux’s move from a student’s project to the world’s most popular operating system by word of mouth, positive press and quality of code is no small feat. While there may be some corporate sponsored case studies in the open source ecosystem they aren’t the norm while in the closed source domain there are regular part of marketing. It’s highly unlikely that if Target was using open source solutions a case study with the depth of detail would have been produced to facilitate reconnaissance.
As mentioned before, the breach started with an email attack/phishing scam at Fazio Mechanical. Brian Krebs reported in February of 2014 that the refrigeration company had been running Malwarebytes Anti-Malware Free edition software on their machines, but that the free edition didn’t include real time scanning. He further goes on to identify the likely malware as Citadel. According to Rahimian et al writing for the National Cyber-Forensics and Training Alliance Canada and Computer Security Laboratory at Concordia University, “Citadel is an advanced information-stealing malware which targets financial information. This malware poses a real threat against the confidentiality and integrity of personal and business data.” Citadel’s platform for code execution is the Windows operating system. It’s system calls are designed for Windows only. Two options would have prevented this malware from functioning. One would be to use the professional grade anti-malware software. Malwarebytes confirmed via email that had Fazio been using the professional version of their software instead of the consumer version Citadel would have been identified and cleaned. The second would have been to run a less vulnerable open source operating system.
For our discussion it’s important to observe the feasibility of running malware on open source systems. As a general rule malware must also conform to the software considerations model. Although its purposes may not be legitimate the mal-actors that employ the software especially in the Target breach were thoughtful professionals who needed software that was accessible, scalable, reasonably priced for the potential pay off, was secure enough to reduce the chances of their being caught, and was functional enough to pull off the job. In theory the software considerations model appears as the hexagon in part one, but in practice the considerations each take different emphasis depending upon the shape of the ecosystem in which they are to work. The case study’s illustration defined the ecosystem much the same way we can build a puzzle by identifying the shape of the missing puzzle pieces. In the open source development model, the outline of that shape has more possibilities making it harder to build software that can integrate with the larger ecosystem, provided that ecosystem doesn’t advertise its shape.
This diversity in open source comes from the second and third order effects of its production philosophy. In the open source community Linus’ law means that as a project grows in popularity it also grows in security as more reviewers identify more bugs. But the open source community’s iconic call for freedom also plays a role in limiting malware. Because people have the freedom to fork there are often more tools to get a job done than the ones approved by a closed sourced vendor. Antergos ships natively with six different desktops. Ubuntu has nine different recognized flavours. Their closed source contenders, Apple and Microsoft, ship with one per desktop operating system iteration. Not only are there more solutions to choose from in open source, but there is a wider variety of implementation of those solutions. Not a perfect example of this, but certainly a visual one, is WordPress. WordPress’ open source website creation tool is a good example of variety of implementation. Time magazine, ESPN, and Fortune have all used WordPress with a wide variety of templates and underlying features each customized to fit their organization’s needs. There are also great examples of diversity for database software, project management software, and a whole host of docker images to choose from as well. On the more technical front, as of April 2014 there were at least four alternatives to OpenSSL with others such as LibreSSL coming into maturity in the months since. Running malware on open source systems is far from impossible, but it does become more unlikely as the popularity and diversity in open source makes it more difficult for complex malware to fit their balance of the software considerations model into an unknown and potentially massively diverse ecosystem.
BlackPOS was the software used in 2013 to exploit the POS machines at Target. The flaw in the Windows operating system was simple enough to be exploited by the 17 year old programmer in Russia who built BlackPOS. As early as May of 2013 (a full six months before the breach) detailed articles about its methods were published online. It uses a memory management exploit to dump the unencrypted credit card information onto the hard drive and later move it to an off site location. While certainly exploiting a vulnerability in Windows, the POS system as a whole had several issues. The in-house product and credit card processing sequence did not encrypt the customer or card information leaving vulnerable opportunities for exploitation. BlackPOS doesn’t work if the card information is encrypted, but BlackPOS could have been blocked or neutralized if Target hadn’t been running Windows on the POS machines.
Basing the largest portion of your businesses income on custom software built to run on Windows has several problems that are neutralized by open source solutions. Because of the closed nature of Windows’ development, companies who build an application for a particular version of Windows are married to that version for the length of its supported lifecycle. On the surface this looks the same as it does for open sourced solutions, but it’s significantly different when it’s time to upgrade. Microsoft and Canonical publish the lifecycle of their operating systems so programmers can predict when updates are necessary, but Canonical’s open model allows application developers to see adjustments to the code early on in the progression and all the way through the beta process. They can download the daily iso and test their application’s functionality with the feature set built into the operating system.
Part of the reason why retailers are slow to upgrade might be because of the uncertainty created by Microsoft’s closed source model. It should now be apparent that this delay in update adoption is more costly than the cure. Home Depot was breached using the same BlackPOS months after Target due to unpatched Windows machines. The closed source development model of Windows fails to fulfil all the aspects of the software considerations model by minimally addressing the issue of maintainability. Although they’ve made improvements the low score on maintainability for previous iterations of their software has contributed to the hesitation of upgrading. While this hesitation is not exclusive to Microsoft they are a major offender in this space.
If Target had decided to open source it’s custom software and built it upon an open source operating system it could have reduced its risk for not only itself but the entire retail industry. Martin Wimpress isn’t a Ubuntu or Debian developer but he does send code upstream for both projects to improve their functionality. Ubuntu MATE’s difference from Ubuntu is four packages, but Martin has found a benefit in sending code and funding upstream to improve the ecosystem and in turn his own project. If Target contributed to an open source point of sale application that they could reskin with their own branding they would be much closer to getting the required eyeballs to reduce the software’s bugs. That level of transparency would have also put pressure on other retail companies to contribute to the project.
One of the biggest arguments for this course of recommendation has emerged over the last several months. When a project goes open source it’s hard for proprietary solutions to compete. Open source development has an edge in the industry and large players are making moves to capitalize on it. Apple has recently released Swift as open source (Apple, 2015). Microsoft’s .NET framework is now on GitHub. A project going open source isn’t as predictable as biological succession but it does seem to be the trend going forward for 2016.
As stated before, closed systems aren’t the only ones with vulnerabilities. Matt Hartley open source contributor to datamation.com says, “if it can execute code, it could be a threat.” Heartbleed wouldn’t have been an issue if open source software was somehow impervious to vulnerabilities. Just as BlackPOS took advantage of a memory error, OpenSSL’s heartbleed vulnerability also dealt with memory management. Unlike its closed source compadre the open software development model allowed the heartbleed flaw to be identified and addressed much quicker than BlackPOS.
In open source communities security flaws aren’t posted on public boards until a patch has been released and had time to be distributed. This limits advertising an exploit in the wild. A lack of understanding this has lead to scrutiny regarding the exact timeline for information release regarding heartbleed. The scrutiny is another advantage of open source development as the attention will only encourage a refinement of the process in the future. Using the timeline from the Sydney Morning Herald we can see an overarching story that highlights the benefits of open source code. First, because the code was open source Neel Mehta of Google Security was able to review the code and identify the flaw on or before March 21st, 2014. The same day other programmers at Google were able to confirm the flaw and issue a patch that they sent upstream while simultaneously applying the patch to their systems making Google’s server infrastructure secure for its users. Because it was open source Google wasn’t reliant upon a third part to approve the patch. They had the freedom to modify and publish it out themselves. Here the company’s incentive for using open source is its ability to quickly adapt when errors are found by implementing the solutions themselves and endearing them with their customers by protecting their data. By Monday April 7th, patches had been released for all the major operating systems involved.
There is ample room for both criticism and compliment in the speed with which this vulnerability was published and patched that is due to the open source methods of development. The criticism about how it was released and to whom has taken quite a bit of attention in the press. The other component that deserves compliment is the ease of the patch. The open source community builds on the Unix philosophy, particularly the command to “write programs that do one thing and do it well.” This is part of the reason why open source solutions have such diversity in their implementation. One person’s doing it well can often lead to a different solution than someone else. OpenSSL’s flaw was potentially catastrophic, but in practice reasonably contained in a few small files enabling the patch to be easily transportable and scalable. Whether or not closed source software can patch as efficiently likely depends on the specifics of the flaw, but in the open source community surgical patching is rather common among distributions in both Linux and the BSD community.
After establishing this model we reviewed different philosophies of open and closed source development drawing heavily upon Martin Wimpress’ over twenty years of experience with open source code development. He declared that it’s not the philosophy that makes it more secure, but rather the review process. We observed how both open and closed source projects use some feedback and review mechanisms as part of software development. We saw how open source development had greater opportunity to include more development more times throughout the developmental processes. Much of the closed source development model is unknown adding uncertainty to any who utilize a closed source project in production.
In part three we began discussing the implementation of open source software with regards to the 2014 cyber attack that breached Target’s point of sale system. Although we mentioned twelve separate attack vectors that were exploited in Target’s breach we discussed how three of them would have been impacted by the implementation of open source solutions. After review of Target’s breach through closed source software, we looked at OpenSSL’s heartbleed vulnerability and briefly observed how the open source community identified and patched the vulnerability.
Throughout this paper I’ve demonstrated the robustness of open source software in reducing cyber attacks. Open source development means a reduction of uncertainty about the code’s effectiveness and complete visibility on the community’s efforts to maintain it over time. This open development also allows others to review how the code achieves its balance of the software considerations model. The open source ecosystem allows freedom to implement custom software solutions creating oddly shaped target vectors that reduce the scalability of malware.
There are two powerful pieces of evidence mentioned in this paper arguing for the use of open source software that are difficult to refute. The first is the fact that the open source ecosystem thrives despite its lack of advertising. It’s about the code. As referenced earlier, Linux is now by far the world’s most popular operating system and one third of the internet’s traffic passes over a single open source project. The second piece of evidence is that two of the largest advocates for the closed source development model are open sourcing projects crucial to their company’s strategies. Microsoft has open sourced .NET and Apple has done the same with Swift. You don’t have to take my word for the robustness of open source with regards to the software consideration model, the popularity of the code’s projects as well as Microsoft and Apple’s move to open source their products should be evidence enough. In order to protect against the cyber attacks that rain down on projects you need an umbrella, and we all know that umbrellas work better when they’re open.
In his 2014 TED presentation Cory Doctorow compares an open system of development to the scientific method and credits the methods for bringing mankind out of the dark ages. Tim Berners-Lee has a very credible claim to patent the technology that runs the internet, but instead has championed for its open development. This open development has launched us forward into a brave new world. Nearly one third of all internet traffic rides on just one openly developed project. Its place of dominance may be unsure as we approach a world with cybersecurity headlines. Those headlines do much to feed the industry of fear resulting in government efforts to close doors on open source efforts.
This paper is a qualitative theoretical discussion regarding cyber security and open source solutions written in three parts. Its goal is to demonstrate that the use of open source technologies reduces vulnerability to cyber attacks. The first part of this paper identifies the difficulties in presenting a software consideration model capable of illustrating the full spectrum of expectations for the performance of today’s code. Previous models merely address basic requirements for execution namely security, functionality & usability. While these aspects are important they fail to take into account modern requirements for maintenance, scalability, price, reliability and accessibility of software. This part of the paper modernizes the model developed by Andrew Waite and presents a clear model for software discussion.
Part two of the paper reviews the open source development model with particular care to illustrate how security considerations are taken into account. A large portion of this section is drawn from a first hand source with over two decades working with open source technology.
Part three looks at potential applications for the open source model of development in regards to Target’s 2013 breach and OpenSSL’s Heartbleed vulnerability. It illustrates how the application of open source solutions could be used to close the security holes that lead to Target’s breach and how the open source development model contributed to patching Heartbleed in quick order.
Part I: Models for Visualizing Software
Software evaluation models are fairly common in the industry. Each helps the intended audience to identify key points of interest for their discussion. Gartner’s magic quadrants are popular ways of visually representing subjects across two dimensional criteria. Gartner’s labels across its sofware dimensional breakdown consists of “Leaders, Visionaries, Niche Players and Challengers” for Gartner’s business clientele within a given area. While these charts can be useful for their audience’s application they are quite narrow in reality.To illustrate the difficulty of finding a good model we can look at the 2013 Gartner Magic Quadrant for Social Software. This quadrant shows Microsoft as an industry leader, Google as a visionary, and VMware as a challenger. The chart completely ignored the actual social software that dominated 2013, Facebook. So while this is what Gartner’s business audience saw, the public saw thousands of youtube videos and websites that walk readers through best practices on how to use facebook as a social platform for business. Gartner’s chart is more in line with the ongoing conversation they’ve built up with their audience over the years and the consulting work they also perform. Beyond discussing it as a potential model, its narrow focus doesn’t make it useful for our purposes in this paper mostly due to the format constraints inherited by the two axis model.
Since Gartner’s model for software doesn’t fit this discussion on software considerations we’ll instead be using an updated version of Andrew Waite’s triad published on infosec in 2010 (Figure 1). In his triad he identifies Security, Usability, and Functionality as the key components of software that must be kept in balance for it to be successful. He specifically wanted to show how “an increase or decrease in any one of the factors will have an impact on the presence of the other two.” Each of these components are crucial in the design and implementation of modern software. Ease of use determines adoption and satisfaction. Functionality determines how useful the software is from a systems standpoint providing real value to the larger production chain of the industry employment of the software. Security is a major requirement for today’s software requirements as vulnerabilities cost companies millions in revenue if exploited. The need for securing the information kept digital in our society is so real that it has prompted the creation of the cyber insurance industry.
To
explain the interrelated nature of these areas Andrew writes, “as an
example, increasing the amount of functionality in an application will
also increase the surface area that a malicious user can attack when
attempting to find an exploitable weakness.” One can also see how
increasing the security of a product can greatly affect its usability
and functionality. If the software is so secure no one can use it, then
it becomes less useful because it becomes less of an asset to the
production line and the employee’s time. This triad does a very good job
illustrating the balance between each of the components listed. While
his 2010 model is certainly applicable, it is a static view of software
in a single snapshot of time. In order to expand the software beyond a
single instance we must add software maintainability as a dimension.Over the past few years we’ve seen security issues in the press due to a lack of software maintenance. This emphasis on maintenance is one of the reasons for inspiring the TechSNAP podcast who’s motto early on was “patch your [explicative].” Software maintenance is a major part of cyber security. Sony’s massive 2011 breach was attributed to running outdated software and the U.S. Navy is still paying Microsoft millions of dollars to maintain Windows XP even though its end of life occurred nearly two years ago. A popular article on programmingisterrible.com discusses that each line of code contains a cost of
maintenance
over time. So, while Andrew Waite’s triad holds true for 2010, in 2016
we’ve learned the importance in both cost to business and customer need
for software that can be maintained in the long term. Projects are still
learning and refining their own particular processes for code
maintenance. In Android Google has learned to move more features to apps
that can be updated through the app store. OwnCloud which powers the
redundancy of CERN’s large data stores recently updated their software
to include fragmentation of certain features to make code maintenance easier.While the above illustrates the need to patch for security issues, the process of patching is a separate component and it’s given a lot of attention in the IT field. Often IT personnel don’t patch due to risk of loss functionality. This is a secondary effect of the maintenance dimensions. This reluctance to patch increases the life cycle of vulnerability exploits. General code improvement is a separate requirement that affects security, usability and functionality. Conversely if code is hard to maintain, than its usability, functionality and security suffer. Because of this additional dimension, I’ve updated Waite’s model illustrated as Figure 2 of this paper. In this illustration we still maintain the interrelated aspects of the earlier work and the need for project managers to strike a balance with each aspect early on.
I reached out to Rix Ryskamp owner of Transcend Products LLC and inventor of U.S. Patent 20090232295 A1 (apparatus, system, and method for automated call initiation) for a review of this chart and he informed me that he applies an additional four criteria for software consideration within his organization namely, scalability, reliability, accessibility, and price. These additional aspects do make the model more complex, but by adding these additional dimensions from someone who not only purchases software to run his business, but also innovates within the space is worth consideration. Now instead of simply focussing on the code we have added dimensions that impact business operations not just code implementation. Due to space requirements I will not directly discuss the interoperability of these each of these additional dimensions beyond saying that price, scalability, and reliability impact whether a particular technology is adopted. Increasing or decreasing these impacts all other dimensions. Increased emphasis on functionality and usability directly impacts the amount of work required and increases the price. Increased emphasis on scalability impacts the larger security and maintainability footprints.
Although
this model has yet to be accepted formally by any particular
organization it seems to be intuitively used for nearly every adoption
of software. Case studies published by major corporations often speak in
these terms. While this paper’s primary purpose is to argue that the
use of open source technologies reduces one’s vulnerabilities to cyber
attacks no discussion on the subject can occur without understanding the
multiple considerations of any software project as they are all
interrelated.We began this discussion in part one to find a model that can be used to facilitate a conversation for software. We reviewed Gartner’s model and noticed its limitations for our conversation due to it being tailored for a specific audience. Andrew Waite’s 2010 triad was functional but a rather static model that didn’t account to changes in software over time. After modifying Waite’s model to include the software’s lifetime we adjusted the model further to include principles of consideration used in business practices by a leader in the field. Now at the conclusion of part one we have a useful model for discussing software that we can reference looking at the adaptability and adoption of software.
Part II: Developmental Differences
In this section we will take an in depth look at coding philosophies and how they impact security. To understand this we need to quickly review the three step process by which all programs are built. All programs begin with lines of instruction. When ready for execution these lines of instruction are converted to a binary format the computer can execute. This process is known as compiling. To a human compiled code appears as a series of one’s and zeros. Compiled code is much more complex for humans to understand but is precisely what computers need to function. This three part process is nearly universal across all software development. Lines of code are written, compiled and executed.Some producers in this marketplace are motivated to share their precompiled lines of code with others. Other producers are motivated to guard their code and restrict access to its human readable content through legal means. The code that is accessible for review is known as open source code and the counterpoint on the other end of the spectrum is closed source. It’s best to view these as philosophies connected on a spectrum. Excluding the two extremes the discussion on closed vs open source differences are better geared for a legal discussion, not a technical one.
Just as there are varying degrees of open and closed source options there are also varying production models for developing and publishing software. To ensure the software is meeting the right combination of items on the software considerations model from part one, some type of review process must exist. The most crucial group of stakeholders are the users themselves. As Eric Raymond stated in his book, The Cathedral & The Bazaar, “Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.”
There are various models that leverage ongoing user feedback as part of software development, one popularly described today is the agile approach to software development. Kendall and Kendall describe the agile approach as being based on four values “communication, simplicity, feedback and courage” while adding that the developmental process is both “interactive and incremental.” Agile absorbs user feedback at multiple opportunities during development. The Systems Development Life Cycle (SDLC) is another model for software development that exists with greater structure than the agile method. In contrast to the agile method the SDLC has more limited user engagements during the developmental process but is still a very effective way to produce deliverable code.
Both agile and the SDLC have internal processes for review and development. While agile is better suited for teams with more flattened hierarchies it still requires a review process before publication. This review process is one of the most significant differences between open and closed sourced software. In a closed source development model the review process is built upon a limited population base. In an open source development model the review process’ population base can cover a broader slice of individuals. Both models use feedback to maximize the balance of the software considerations model.
The closed source development model could include a greater quantity and quality of programmers and participants than an open source one, but due to its closed nature it is difficult to capture accurate information to do a quantitative and qualitative comparison. Both development models leverage public input. Apple heavily enforces its very restrictive non-disclosure agreement with regards to development, but still releases public betas of their software to registered participants. Google, Microsoft and code other companies have similar practices to gather feedback from early adopters. While the closed source model does leverage public input it does so towards the end of a closed development cycle, and the testing does not generally include an audit of the code (Android Open Source Project is an exception to this).
In contrast the open source model leverages public input and audit very early on in the process. Ubuntu, a Debian based Linux distribution, has a regular release cycle named after the month and year of the release. Just hours after its 15.10 release, the daily .iso for 16.04 was already available for download. Early reviewers help to change the direction of the code and fix mistakes early on in the process. Martin Wimpress is the lead developer for Ubuntu MATE one of the top twenty Linux distritubtions searched for on DistroWatch.com. Martin explained the power that early user feedback has on his project. In an interview he discussed how one of his contributors is very conscious of shell script injection vulnerabilities. Martin describes how the general MATE developers are mindful of security but it’s not one of the things they have at the forefront of their mind when writing code. He goes onto explain how this contributor regularly files bug reports as the MATE team posts patches and updates which unknowingly contain script injection vulnerabilities. While this example illustrates the effort on the security portion of the software consideration model in open source other aspects receive similar attention. As mentioned earlier the octagonal shaped consideration model is rather intuitive to those in the industry. Chris Fisher has been reviewing open source software as part of his nearly eight year podcast, The Linux Action Show. Listeners of his reviews on the KDE and Gnome desktops will often hear him discuss many of the segments of this consideration model.
The contrast between open and closed source is worth some consideration. Martin Wimpress also described how his development process compares with its closed source alternatives:
Because you can have people with a specific security interest looking at code through their eyes they may well see things and discover things that the original developers don’t see because they’re snow blind to their domain. They’re focused on functionality and features. I’m not saying that they’re not thinking about security, but they may not have the expertise or the nature of somebody that’s looking at it from a particular angle, and this is where proprietary software isn’t as secure in that respect because it’s only those people that have access to that source code tree can provide any commentary feedback for review.This is why within the first month after release of the first iPhone CVE-2007-3944 was released with a vulnerability score of 9.3 out of 10. To some degree both models adopt the Linus Law which states “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.” While the closed source model does have feedback mechanisms, those feedback mechanisms aren’t designed for security audits by a wide population at the source code level. In both models the popularity of a product contributes to its security, open source by facilitating more direct reviews and closed source by increasing the capital available to hire more talented reviewers.
While a close sourced model has limitations due to its unknown development, simply being open source doesn’t equate to greater security. Several open source projects don’t have the user base necessary to attract the level of technical users capable of submitting bug reports and contributing code. In some cases projects that do have a substantial user base but don’t have a system for integrating the feedback will also fail to adjust. Other open source projects, such as Linux Mint, just make questionable security choices. Again Martin Wimpress offered a succinct summation during our interview, “open source projects are more secure when there’s a peer review process in place” and the open nature of development allows that peer review process to be scrutinized for its effectiveness. In open source the ecosystem can be evaluated while in a closed model the ecosystem is largely unknown.
Part III: Threading the Needle to Target
Fazio Mechanical services is a refrigeration company based out of Sharpsburg, Pennsylvania and was the first step of twelve that lead to the breach at Target in 2013. Teri Radichel’s case study for the SANS Institute summarizes the timeline for the breach from known credible sources. Her categorization of twelve separate attack vectors is a good framework for our review. In sequence these are, reconnaissance, email attack (malware installed on vendor machine), use of vendor credentials, exploited vendor portal vulnerabilities, network infiltration and communication, misconfigured systems and vulnerable domain controller, malware installed on point of sale (POS) systems, card data scraped from memory, data removed from POS machines to corporate LAN, data moved to drop locations, failure to respond to FireEye alerts, and cards stolen on black market. Information for three of these is readily available and relevant to our conversation regarding open source, namely reconnaissance, email attack, and malware installed on point of sale systems. While Teri’s solutions in these areas can be applied by primarily refining Target’s use of its already existing structure I will show how some of these vectors are instantly neutralized via open source solutions. Because the breach required a successful procession of vulnerabilities any one of these solutions would have neutralized the threat.Reconnaissance was done in part through a Microsoft case study and although the links have been been removed from Microsoft’s website the PDF can still be downloaded from Microsoft.com. The case study specifies the hardware and software running throughout the network, the size of the network and hints at methods for remote updating. To nefarious actors the case study contains a good starting point to justify a malicious operation. It outlines the shape of a future attack. All the software considerations discussed in part one apply to both malicious and legitimate applications. Starting a project like this has an associated cost of finances and time. Functional software must be accessible and scalable in order to justify the cost of the breach with its associated risk of getting caught. Even mal-actors conduct cost benefit analysis and in this case the reconnaissance helped paint the picture of the amount and type of work required to pull off the heist.
While there are similarly large publicly shared open source companies that publish case studies such as Red Hat, most projects in the open source community don’t have the funding or need to advertise their products to attract customers. While Red Hat does publish case studies to attract customers the code generally speaks for itself. Red Hat is one player in an ecosystem that includes SUSE, Ubuntu and FreeBSD. Kris Moore, project manager for PCBSD, as recently as January reminded his audience of BSD’s slogan to “shut up and code.” While a novel saying, it’s evidence that the open source community in general is more concerned about what you write and how well it performs than writing case studies about it to attract new users. Linux has similarly relied upon the experience of users and word of mouth with users emphasising different aspects of the software consideration model. Linux’s move from a student’s project to the world’s most popular operating system by word of mouth, positive press and quality of code is no small feat. While there may be some corporate sponsored case studies in the open source ecosystem they aren’t the norm while in the closed source domain there are regular part of marketing. It’s highly unlikely that if Target was using open source solutions a case study with the depth of detail would have been produced to facilitate reconnaissance.
As mentioned before, the breach started with an email attack/phishing scam at Fazio Mechanical. Brian Krebs reported in February of 2014 that the refrigeration company had been running Malwarebytes Anti-Malware Free edition software on their machines, but that the free edition didn’t include real time scanning. He further goes on to identify the likely malware as Citadel. According to Rahimian et al writing for the National Cyber-Forensics and Training Alliance Canada and Computer Security Laboratory at Concordia University, “Citadel is an advanced information-stealing malware which targets financial information. This malware poses a real threat against the confidentiality and integrity of personal and business data.” Citadel’s platform for code execution is the Windows operating system. It’s system calls are designed for Windows only. Two options would have prevented this malware from functioning. One would be to use the professional grade anti-malware software. Malwarebytes confirmed via email that had Fazio been using the professional version of their software instead of the consumer version Citadel would have been identified and cleaned. The second would have been to run a less vulnerable open source operating system.
For our discussion it’s important to observe the feasibility of running malware on open source systems. As a general rule malware must also conform to the software considerations model. Although its purposes may not be legitimate the mal-actors that employ the software especially in the Target breach were thoughtful professionals who needed software that was accessible, scalable, reasonably priced for the potential pay off, was secure enough to reduce the chances of their being caught, and was functional enough to pull off the job. In theory the software considerations model appears as the hexagon in part one, but in practice the considerations each take different emphasis depending upon the shape of the ecosystem in which they are to work. The case study’s illustration defined the ecosystem much the same way we can build a puzzle by identifying the shape of the missing puzzle pieces. In the open source development model, the outline of that shape has more possibilities making it harder to build software that can integrate with the larger ecosystem, provided that ecosystem doesn’t advertise its shape.
This diversity in open source comes from the second and third order effects of its production philosophy. In the open source community Linus’ law means that as a project grows in popularity it also grows in security as more reviewers identify more bugs. But the open source community’s iconic call for freedom also plays a role in limiting malware. Because people have the freedom to fork there are often more tools to get a job done than the ones approved by a closed sourced vendor. Antergos ships natively with six different desktops. Ubuntu has nine different recognized flavours. Their closed source contenders, Apple and Microsoft, ship with one per desktop operating system iteration. Not only are there more solutions to choose from in open source, but there is a wider variety of implementation of those solutions. Not a perfect example of this, but certainly a visual one, is WordPress. WordPress’ open source website creation tool is a good example of variety of implementation. Time magazine, ESPN, and Fortune have all used WordPress with a wide variety of templates and underlying features each customized to fit their organization’s needs. There are also great examples of diversity for database software, project management software, and a whole host of docker images to choose from as well. On the more technical front, as of April 2014 there were at least four alternatives to OpenSSL with others such as LibreSSL coming into maturity in the months since. Running malware on open source systems is far from impossible, but it does become more unlikely as the popularity and diversity in open source makes it more difficult for complex malware to fit their balance of the software considerations model into an unknown and potentially massively diverse ecosystem.
BlackPOS was the software used in 2013 to exploit the POS machines at Target. The flaw in the Windows operating system was simple enough to be exploited by the 17 year old programmer in Russia who built BlackPOS. As early as May of 2013 (a full six months before the breach) detailed articles about its methods were published online. It uses a memory management exploit to dump the unencrypted credit card information onto the hard drive and later move it to an off site location. While certainly exploiting a vulnerability in Windows, the POS system as a whole had several issues. The in-house product and credit card processing sequence did not encrypt the customer or card information leaving vulnerable opportunities for exploitation. BlackPOS doesn’t work if the card information is encrypted, but BlackPOS could have been blocked or neutralized if Target hadn’t been running Windows on the POS machines.
Basing the largest portion of your businesses income on custom software built to run on Windows has several problems that are neutralized by open source solutions. Because of the closed nature of Windows’ development, companies who build an application for a particular version of Windows are married to that version for the length of its supported lifecycle. On the surface this looks the same as it does for open sourced solutions, but it’s significantly different when it’s time to upgrade. Microsoft and Canonical publish the lifecycle of their operating systems so programmers can predict when updates are necessary, but Canonical’s open model allows application developers to see adjustments to the code early on in the progression and all the way through the beta process. They can download the daily iso and test their application’s functionality with the feature set built into the operating system.
Part of the reason why retailers are slow to upgrade might be because of the uncertainty created by Microsoft’s closed source model. It should now be apparent that this delay in update adoption is more costly than the cure. Home Depot was breached using the same BlackPOS months after Target due to unpatched Windows machines. The closed source development model of Windows fails to fulfil all the aspects of the software considerations model by minimally addressing the issue of maintainability. Although they’ve made improvements the low score on maintainability for previous iterations of their software has contributed to the hesitation of upgrading. While this hesitation is not exclusive to Microsoft they are a major offender in this space.
If Target had decided to open source it’s custom software and built it upon an open source operating system it could have reduced its risk for not only itself but the entire retail industry. Martin Wimpress isn’t a Ubuntu or Debian developer but he does send code upstream for both projects to improve their functionality. Ubuntu MATE’s difference from Ubuntu is four packages, but Martin has found a benefit in sending code and funding upstream to improve the ecosystem and in turn his own project. If Target contributed to an open source point of sale application that they could reskin with their own branding they would be much closer to getting the required eyeballs to reduce the software’s bugs. That level of transparency would have also put pressure on other retail companies to contribute to the project.
One of the biggest arguments for this course of recommendation has emerged over the last several months. When a project goes open source it’s hard for proprietary solutions to compete. Open source development has an edge in the industry and large players are making moves to capitalize on it. Apple has recently released Swift as open source (Apple, 2015). Microsoft’s .NET framework is now on GitHub. A project going open source isn’t as predictable as biological succession but it does seem to be the trend going forward for 2016.
As stated before, closed systems aren’t the only ones with vulnerabilities. Matt Hartley open source contributor to datamation.com says, “if it can execute code, it could be a threat.” Heartbleed wouldn’t have been an issue if open source software was somehow impervious to vulnerabilities. Just as BlackPOS took advantage of a memory error, OpenSSL’s heartbleed vulnerability also dealt with memory management. Unlike its closed source compadre the open software development model allowed the heartbleed flaw to be identified and addressed much quicker than BlackPOS.
In open source communities security flaws aren’t posted on public boards until a patch has been released and had time to be distributed. This limits advertising an exploit in the wild. A lack of understanding this has lead to scrutiny regarding the exact timeline for information release regarding heartbleed. The scrutiny is another advantage of open source development as the attention will only encourage a refinement of the process in the future. Using the timeline from the Sydney Morning Herald we can see an overarching story that highlights the benefits of open source code. First, because the code was open source Neel Mehta of Google Security was able to review the code and identify the flaw on or before March 21st, 2014. The same day other programmers at Google were able to confirm the flaw and issue a patch that they sent upstream while simultaneously applying the patch to their systems making Google’s server infrastructure secure for its users. Because it was open source Google wasn’t reliant upon a third part to approve the patch. They had the freedom to modify and publish it out themselves. Here the company’s incentive for using open source is its ability to quickly adapt when errors are found by implementing the solutions themselves and endearing them with their customers by protecting their data. By Monday April 7th, patches had been released for all the major operating systems involved.
There is ample room for both criticism and compliment in the speed with which this vulnerability was published and patched that is due to the open source methods of development. The criticism about how it was released and to whom has taken quite a bit of attention in the press. The other component that deserves compliment is the ease of the patch. The open source community builds on the Unix philosophy, particularly the command to “write programs that do one thing and do it well.” This is part of the reason why open source solutions have such diversity in their implementation. One person’s doing it well can often lead to a different solution than someone else. OpenSSL’s flaw was potentially catastrophic, but in practice reasonably contained in a few small files enabling the patch to be easily transportable and scalable. Whether or not closed source software can patch as efficiently likely depends on the specifics of the flaw, but in the open source community surgical patching is rather common among distributions in both Linux and the BSD community.
Conclusion
In this paper I’ve attempted to demonstrate that use of open source software development reduces one’s risk of cyber attack than software created with a closed source development model. In part one of this paper we discussed software consideration models. After reviewing the Gartner’s magic quadrants we built a software model built upon Andrew Waite’s 2010 triad. This updated model includes requirements for both software functionality and its implementation. We saw that any discussion on security must involve other software considerations as these are interconnected aspects of any software project.After establishing this model we reviewed different philosophies of open and closed source development drawing heavily upon Martin Wimpress’ over twenty years of experience with open source code development. He declared that it’s not the philosophy that makes it more secure, but rather the review process. We observed how both open and closed source projects use some feedback and review mechanisms as part of software development. We saw how open source development had greater opportunity to include more development more times throughout the developmental processes. Much of the closed source development model is unknown adding uncertainty to any who utilize a closed source project in production.
In part three we began discussing the implementation of open source software with regards to the 2014 cyber attack that breached Target’s point of sale system. Although we mentioned twelve separate attack vectors that were exploited in Target’s breach we discussed how three of them would have been impacted by the implementation of open source solutions. After review of Target’s breach through closed source software, we looked at OpenSSL’s heartbleed vulnerability and briefly observed how the open source community identified and patched the vulnerability.
Throughout this paper I’ve demonstrated the robustness of open source software in reducing cyber attacks. Open source development means a reduction of uncertainty about the code’s effectiveness and complete visibility on the community’s efforts to maintain it over time. This open development also allows others to review how the code achieves its balance of the software considerations model. The open source ecosystem allows freedom to implement custom software solutions creating oddly shaped target vectors that reduce the scalability of malware.
There are two powerful pieces of evidence mentioned in this paper arguing for the use of open source software that are difficult to refute. The first is the fact that the open source ecosystem thrives despite its lack of advertising. It’s about the code. As referenced earlier, Linux is now by far the world’s most popular operating system and one third of the internet’s traffic passes over a single open source project. The second piece of evidence is that two of the largest advocates for the closed source development model are open sourcing projects crucial to their company’s strategies. Microsoft has open sourced .NET and Apple has done the same with Swift. You don’t have to take my word for the robustness of open source with regards to the software consideration model, the popularity of the code’s projects as well as Microsoft and Apple’s move to open source their products should be evidence enough. In order to protect against the cyber attacks that rain down on projects you need an umbrella, and we all know that umbrellas work better when they’re open.
Author Note:
Jacob F. Roecker is a student at UMUC. Correspondence concerning this article should be addressed to Jacob F. Roecker, jacob@jfroecker.com.
License: Attribution–ShareAlike 4.0 International
No comments:
Post a Comment