by clicking on the page. A slider will appear, allowing you to adjust your zoom level. Return to the original size by clicking on the page again.
the page around when zoomed in by dragging it.
the zoom using the slider on the top right.
by clicking on the zoomed-in page.
by entering text in the search field and click on "In This Issue" or "All Issues" to search the current issue or the archive of back issues respectively.
by clicking on thumbnails to select pages, and then press the print button.
this publication and page.
displays a table of sections with thumbnails and descriptions.
displays thumbnails of every page in the issue. Click on a page to jump.
allows you to browse through every available issue.
GCN : November and December 2014
CYBEREYE BY BRIAN ROBINSON THIS YEAR HAS BEEN "Annus Horribilis" for open source software used in government. One of the latest examples involved Drupal, a popular, open source content management system that s been used for an increasing number of agency websites, including the White House. An announcement from the organization that oversees Drupal warned several weeks ago of a vulnerability that would allow an attacker to use an SQL injection, where malware can be inserted into a system because of an error in database code, for example. Depending on the content of the attacker s re- quest, it said, the attack could lead to privilege escalation, arbitrary PHP execution or other scenarios that put data at risk. However, the real danger of this vulnerability was revealed several weeks later, when the Drupal organization put out another announce- ment warning that, even if the patch issued at the time of the original announce- ment was applied, timing was critical. If sites weren t patched "within hours" of the vulnerability announcement, the damage may have already been done. Automated attacks began compromising sites shortly after the vulnerability was revealed, and those who waited to patch their systems then should assume their sites were compromised. Even if the system appears to be patched, the Drupal organization warned, at- tackers may have "fixed" it themselves after they injected their malware, in order to keep other attackers out and to try and fool IT adminis- trators into thinking it was safe. Attackers may also have created backdoors to later get into a ected systems . If timely patches weren t applied, then the Drupal se- curity team outlined a lengthy process required to restore a website to health. Among the steps were: • Take the website o ine by replacing it with a static HTML page. • Notify the server s adminis- trator emphasizing that other sites or applications hosted on the same server might have been compromised via a backdoor installed by the initial attack. • Consider obtaining a new server, or otherwise remove all the website s files and da- tabase from the server. (Keep a copy safe for later analysis.) • Restore the website (Drupal files, uploaded files and database) from backups from before Oct. 15, 2014. • Update or patch the re- stored Drupal core code. This has been a tough year for open source. The Heart- bleed OpenSSLbug revealed in April was considered "one of the scariest ever" in terms of its potential for attackers to get access to data. A steady stream of scares followed, and by October when the Shellshock bug in Linux and Unix operating systems was announced people seemed to be su ering from bug fatigue, even though Shellshock was deemed as potentially damag- ing as Heartbleed. Consequently, warning bells started ringing, again, about the inherent security of open source software. As the theory goes, open source is, by nature, open to the widest range of bad guys who could compromise it. Various indus- try types have tried to down- play that, however, putting it down to human mistakes that could happen anywhere. Others point out that most of the compromised software has one thing in common: it was built on pre-fabricated modules. That s generally considered a benefit. Because developers don t have to repeat what s gone before, they can use a more Lego-like approach and only write code where it s needed. That leads to a much speed- ier time to market, but it also means that whatever errors are included in those mod- ules gets passed along. Some security vendors estimate that as much as 90 percent of the code used for in-house de- velopments is based on these components. We need more and better tools that scan these compo- nents for potential vulnerabil- ities before they are tied into actual products. That s some- thing the National Institute of Standards and Technology, for example, has recognized with its recent e ort to develop better guidelines for systems and software design. On a related note, Google recently came out with its nogotofail tool that can be used to test networks for weak transport layer secu- rity and secure socket layer connections. That won t ad- dress every bug out there -- it doesn t address the Drupal bug, for example -- but it will go some way toward fixing the kinds of vulnerabilities that Heartbleed and similar bugs introduce. • Attacks on open source call for better design We need more and better tools that scan components for potential vulnerabilities before they are tied into actual products. 14 GCN NOVEMBER/DECEMBER 2014 • GCN.COM