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 : August 2014
IT SECURITY has recently gotten a lot of attention in the mainstream press for all the wrong reasons -- like the Target hack that compromised mil- lions of credit card numbers or the Heartbleed bug in OpenSSL that had everyone scrambling. Government IT systems are not immune and it isn t hard to see why. With agency budgets already stretched to their limits, bolting security measures onto complex architectures com- prised of applications of myriad ages, technologies and levels of quality is virtually impossible. One lesson from these fail- ures is that the cost and techni- cal challenge of adding security after the fact are prohibitive. As a software engineer, I believe one thing we can do to begin to address this crisis is to ensure that we build security into all new software applications. Let s consider some steps developers and managers can take. 1. Keep it simple. This might seem obvious, but never underestimate the ability of a developer to devise a compli- cated solution to a problem -- or a perceived problem. Complexity is the death of all software and architectures, and complexity compounds itself with amazing speed. Develop- ers must remain vigilant at every decision point to take the simplest path possible to achieve the desired functional- ity. Simpler and leaner code is easier to maintain and evaluate for possible vulnerabilities. 2. Limit resource access. Virtu- ally every application needs to connect to a database or to files on disk, and this access must be restricted. In a Windows archi- tecture, for example, developers can integrate IIS with Windows Authentiation if users are on the same domain as the server. For anonymous database access, create a single user represent- ing the application and limit its permissions substantially. Less intuitive is cleaning up after accessing resources. For databases, be sure to close connections or return them to the pool; for files, close file I/O abstractions. Use the built-in facilities of the programming language to help. In Java, this would mean try-with-resources and AutoCloseable. Consider also using a tool comparable to Jasypt to encrypt values in configuration files governing access to sensitive resources. And by now, do I really need to even discuss SQL Injection? 3. Be vigilant with dependen- cies. Speaking of libraries, most projects depend heavily on third-party libraries -- open- source and otherwise. If those developers haven t read this column or lack diligence, you could introduce vulnerabilities by using them. I absolutely do not advocate eschewing libraries and writing everything yourself. Rather, ensure libraries are actively maintained (particularly with open source) and address any concerns via forums or paid support. 4. Handle errors gracefully. Have you ever used a Web ap- plication where an error oc- curred and the gory details were displayed in the browser? Aside from a poor user expe- rience, revealing the technical details of an application isn t ideal for security. Never swallow errors and instead log them immediately. Also a fault barrier provides a clean mechanism for handling errors gracefully while relieving developers of the burden. 5. Prefer immutability. Mu- tability is the ability to change values in code after they ve been created. In object-oriented (OO) languages, basic mutabil- ity is common, and objects can even be cloned after creation. Another example derives from inheritance, perhaps the most powerful feature of OO. This endows new code with the properties of existing code. Mutability makes code more complex while introducing the potential for hacks. Immutability makes code simpler, thread-safe and less vulnerable. Functional lan- guages either forbid or make it di cult to write mutable code, but OO languages demand dis- cipline from developers to write immutable code. 6. Automate security test- ing. In my first GCN column, I advocated automated testing to build quality into applica- tions. The same approach can expose flaws in code that can be exploited. While not security testing tools per se, FindBugs for Java and FxCop for .NET identify unused code, memory leaks, resource cleanup failures and other problems. I am unaware of viable open- source security testing tools, so you will likely need to invest in the tool that works best for your situation. Look for tools that work with IDEs like Eclipse and that can be assimilated into your continuous integration infrastructure. If the tool itself can t be automated, consider an automatable script that runs it nightly. For a more thorough discus- sion of ways to build security into applications during devel- opment, check out the guidance from the Open Web Application Security Project. • --- Neil A. Chaudhuri is founder and president of Vidya and has over a decade of experience building complex software projects for commercial and government clients. INDUSTRY INSIGHT BY NEIL CHAUDHURI 6 ways to build security into new applications With agency budgets stretched to their limits, bolting security measures onto complex architectures is virtually impossible. GCN AUGUST 2014 • GCN.COM 17