Passwords
Passwords were discussed as they are a significant security problem, greatly misunderstood and one that users can take action to improve. Random character passwords are almost impossible to remember and, as a result, are often written down (usually on a sticky note under the computer) which subverts security completely (Figure 5). Unfortunately, people are not very adept on their own at creating secure passwords. Passwords are usually created by using family member information; sports or hobby details; quotes from books, television or movies; or with leetspeak which is substituting numbers or symbols for letters such as a “3” for an “e” or “@” for an “a”. However, none of these methods are secure. The hacker community has spent a great effort creating dictionaries to help them uncover passwords when these methods are used. The class discussed Diceware passphrases* and highlighted the need for a better password creation paradigm to easily and greatly improve security.
Figure 5: Cartoon of Creating Passwords https://xkcd.com/936/
The issues of memorability, security, calculability and elevation of security were discussed. The Diceware approach involves the user rolling a set of dice and then matching the resulting group of numbers to words in a large Diceware dictionary several time to create a phrase. The Diceware website compares the security strength of their type of password generation to normal techniques to generate sixteen character random passwords. The Diceware passphrase is much easier to remember by grouping the words together in small sets or creating a sentence or small story they tell. This method of selecting random words from a large dictionary results in a mathematically significant number of possible combinations. Selecting “random” words from memory is actually not a large enough dictionary as an individual will usually select from about 2000 words. Additionally, the Diceware words are not related to any specific characteristic of the user which prevents the passphrase from being guessed by an attacker knowing information about the user. The concept of password managers was discussed as well to help solve the problem of the considerable number of different passwords that are needed today.
Testing Tools
Finally, the topic of testing tools to support secure code development was summarized. There exist free open-source and commercially available testing tools. Entities such as the National Security Agency’s Center for Assured Software have spent effort comparing these tools and identifying what types of weaknesses they do and do not find. The bottom line is that no one tool will find all the weaknesses in code so using two or three will find the most. Additionally, a data correlation tool will help remove the duplicates that the tools find and can present the data in a report format. These tools can help a developer during the coding process to find accidental issues similar to how compiler errors are used during development. However, even with using multiple tools, a major portion of the weaknesses are not found. This is why it is critical for software developers to strive to fundamentally understand code weaknesses so they can vigilantly work to keep them from existing in the design, architecture and code in the first place.
Software Assurance – Summary & Take Away Message
At the end of the week, the students were surveyed on their experiences with and opinions of the different classes. The responses and discussions were unanimous in that most developers, even experienced ones, had not previously been exposed to secure coding practices or vulnerable code detection. Additionally, they had not been aware of how software could be exploited, the impact of that exploitation or how to detect and fix the vulnerabilities in their code.
Teaching the classes was rewarding as the students remained engaged throughout the entire week and asked good questions. Also, they indicated they were going to take what they had learned back to their offices to check their code for vulnerabilities. Additionally, they requested we provide the training to their team members. Most importantly, they understood their role in the cyber problem; had taken ownership; and would be moving forward to practice software assurance during their daily development lives. Given this feedback, the class had achieved its goals and the training was a success. The next goal was to distribute the training far and wide and also support training the program managers to plan for, budget and support software assurance as a tool to defend our military systems.
Conclusion
Armed with the hacker mindset and safe coding strategies, a developer can “know the enemy” and “know yourself,” which if one agrees with Sun Tzu, is the key to being successful at securing our national defenses to win the battles against the cyber enemy.
References
- Feiman Joseph, “Maverick Research: Stop Protecting Your Apps; It’s Time for Apps to Protect Themselves”. (https://www.gartner.com/doc/2856020/maverick-research-stop-protecting-apps)
- Galvin, D., L. Giles, and G. Stade. “Sun Tzu: The Art of War.” (2003).
- http://theinstitute.ieee.org/special-reports/special-reports/10-recommendations-for-avoiding-software-security-design-flaws
- http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf
- DoDI 5200.44 – Protection of Mission Critical Functions to Achieve Trusted Systems and Networks (TSN) – (http://www.dtic.mil/whs/directives/corres/pdf/520044p.pdf)
- National Defense Authorization Act for Fiscal Year 2013 (2013 NDAA S933) (http://www.dtic.mil/congressional_budget/pdfs/FY2013_pdfs/AUTH_CRPT-112hrpt705.pdf)
- http://www.cyber.umd.edu/sites/default/files/documents/symposium/fisher-HACMS-MD.pdf
- http://world.std.com/~reinhold/diceware.html