Secure Software Development: A Security Programmer’s Guide

1. Secure Software Development: A Security Programmer’s Guide Chapter 4 Getting Organized: What to Do on Day One

2. Objectives • Understand the Application Guide • Know how success breeds success • Define coding conventions Secure Software Development: A Security Programmer’s Guide, First Edition

3. The Application Guide • Organizations are realizing how inefficient the duplication of data is while they struggle to do more with fewer resources • When developers arrive on a project, they usually come from different hiring sources • Contractors might even be from different contracting houses • Some might physically be in other countries Secure Software Development: A Security Programmer’s Guide, First Edition

4. The Application Guide (continued) • Application Guide connects developers to other developers and applications to other applications • The following is what you need to know about starting this guide: • Defining the Application Guide • Creating an Application Guide • Risks of not using an Application Guide • Risks of using an Application Guide • Why you should not hoard secrets Secure Software Development: A Security Programmer’s Guide, First Edition

5. The Application Guide (continued) • Defining the Application Guide • Tool that provides the blueprint of how a developer codes software on a specific application • It provides working “how-to” instructions for developers • Documents project details, such as standards, rules, and coding conventions • Tool that holds the team together and ensures that all code is created equal Secure Software Development: A Security Programmer’s Guide, First Edition

6. The Application Guide (continued) • Defining the Application Guide (continued) • Documents step-by-step instructions on how to create the development environment and process • Where to acquire the development tools • Where are the tools located on your hard drive • How do you configure tools • Application design • Where to find license information • Where to find deployment instructions • Where to push code into production (server names, IP addresses) Secure Software Development: A Security Programmer’s Guide, First Edition

7. The Application Guide (continued) • Creating an Application Guide • Creating the Application Guide requires detailed specifics of the project • Some of these specifics might not be defined at the time that the document is initially created • Normally takes several iterations of “trial and error” before an Application Guide starts to work for a team • Creation of an Application Guide starts on day one and never finishes until the software is fully matured and in maintenance mode Secure Software Development: A Security Programmer’s Guide, First Edition

8. The Application Guide (continued) • Creating an Application Guide (continued) • When the Application Guide Is Created • Before the development phase • The Application Guide is created after the software requirements and design are complete • This guide starts off as a simple Microsoft Word document • Introduces the application’s name, provides an empty table of contents, and gives a placeholder for revision information Secure Software Development: A Security Programmer’s Guide, First Edition

9. The Application Guide (continued) • Creating an Application Guide (continued) • Who Creates the Application Guide (continued) • It is the lead developer’s responsibility to initiate and maintain this guide • Written agreement created by the developers for the developers • Team decides which tools to use, which conventions to uphold, and any frameworks that need to be followed • Guide is created in a democratic fashion Secure Software Development: A Security Programmer’s Guide, First Edition

10. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Not Using an Application Guide • You don’t have to create an Application Guide • There are millions of developers out there right now who create software without one • A lot of time goes into reading software white papers and APIs trying to reinstall software that you already had working • It takes a developer an average of 12 hours with an Application Guide to successfully install and configure all the tools he needs to start coding Secure Software Development: A Security Programmer’s Guide, First Edition

11. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Not Using an Application Guide (continued) • Without an Application Guide to hold the team to certain guidelines, it’s easy to lose control • Nothing is holding the team members accountable • Decrease quality • Increase the likelihood of security vulnerabilities • Team gets lax in the development methodology Secure Software Development: A Security Programmer’s Guide, First Edition

12. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Using an Application Guide • The owner’s manual effect • The possibility that developers might give up on it • The idea that it’s just another artifact to babysit Secure Software Development: A Security Programmer’s Guide, First Edition

13. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Using an Application Guide (continued) • More documentation • No one likes to create it, read it, or maintain it, but we all need it • Mere mention of it makes eyes roll • Here’s the key to documentation: make it useful and relevant • Granted, it’s hard to write detailed how-tos Secure Software Development: A Security Programmer’s Guide, First Edition

14. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Using an Application Guide (continued) • The owner’s manual effect • The Application Guide’s role is a lot like the owner’s manual of that new 64-inch flat screen • At first, the owner’s manual is the thing you rely on • But, after you get used to channel surfing and plugging in all your media, you might never open up that manual again • Make sure it stays accurate and up to date Secure Software Development: A Security Programmer’s Guide, First Edition

15. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Using an Application Guide (continued) • The possibility that developers might give up on it • When these scenarios start to pop up on the development team, other developers will start to give up • When organized chaos breaks out in the development team, egos come into play • You start to wonder, “Why am I trying so hard when others don’t?” • Other developers who do not follow an Application Guide might get an “award” from management because they might have coded more quickly Secure Software Development: A Security Programmer’s Guide, First Edition

16. The Application Guide (continued) • Creating an Application Guide (continued) • Risks of Using an Application Guide (continued) • The idea that it’s just another artifact to babysit • As a developer, you are going to have to keep track of many software artifacts • Keep track of documents • Maintain state: Keep all software artifacts relevant takes time • As important as the Application Guide is to you, some feel that it is just one more document Secure Software Development: A Security Programmer’s Guide, First Edition

17. The Application Guide (continued) • Don’t Hoard Your Secrets • Documenting how your application works isn’t a bad thing • You grow in this profession by: • Mastering your craft • Keeping current • Implementing newer technologies where and when they make sense • Don’t think that you can make yourself valuable by writing complicated code in four different computer languages using 20 different open source frameworks Secure Software Development: A Security Programmer’s Guide, First Edition

18. Success Breeds Success: The Benefits • Getting that first successful project with an Application Guide under your belt is the hardest • It takes practice • Trial and error • However, after you do, the project will run itself • The developers will communicate more effectively with one another • The developers will communicate more effectively with the business analyst • This cohesion will produce better results both in the quality and security aspects of the code Secure Software Development: A Security Programmer’s Guide, First Edition

19. Success Breeds Success: The Benefits (continued) • When team members work together instead of against one another, the sum of the results is always greater than the two parts • This positive cohesion will spill out into the code • Long-lasting working relationships with one another • Other project managers will take note of how well your team works together • Others will ask, “What is it that makes your team successful, and how can I implement some of that into my project?” Secure Software Development: A Security Programmer’s Guide, First Edition

20. Success Breeds Success: The Benefits (continued) • A successful implementation of the Application Guide will have: • Benefits for the industry • Benefits for the organization • Benefits in the cube Secure Software Development: A Security Programmer’s Guide, First Edition

21. Success Breeds Success: The Benefits (continued) • Benefits for the Industry • The Application Guide is the document that gets to the granular level of detail that the developer needs • The Application Guide can be used as an industry standard guideline if accepted by the IEEE or ISO • If an Application Guide works on an individual project, it is transferred to other projects within an organization and continues on with success • Hiring IT talent on a contract basis is very common in this industry, so it is very common to see the same individual in many companies Secure Software Development: A Security Programmer’s Guide, First Edition

22. Success Breeds Success: The Benefits (continued) • Benefits to the Organization • Over time, you will find that other developers, managers, and organizations will be interested in what made your process so successful • As each application uses an Application Guide and a standard approach to software development, all code will start to look and act the same • The Application Guide is a powerful mechanism that can be used to streamline a lot of redundant processing Secure Software Development: A Security Programmer’s Guide, First Edition

23. Success Breeds Success: The Benefits (continued) • Benefits to the Organization (continued) • One company can have multiple departments, with each department having multiple applications Secure Software Development: A Security Programmer’s Guide, First Edition

24. Success Breeds Success: The Benefits (continued) • Benefits to the Organization (continued) • Code Reuse • If all the code on a given application was created with the same characteristics and design across all modules, there would be a lot of reusable components • Cross-Training • A developer will be able to move from one project to another with little to no learning curve • Awareness • Knowing how the application’s code is written, what the code can do, and what the code cannot do is half the battle in analysis • Quality Awareness • Secure code starts with quality, and the Application Guide definitely strives for quality Secure Software Development: A Security Programmer’s Guide, First Edition

25. Success Breeds Success: The Benefits (continued) • Benefits in the Cube • Using an Application Guide will bring many benefits to you and the development team • All developers working from the same page • Provide them with one common vision of how the code should be • Where it’s going to be • What it’s going to be Secure Software Development: A Security Programmer’s Guide, First Edition

26. Success Breeds Success: The Benefits (continued) • Benefits in the Cube (continued) • The Application Guide in the cube will do the following: • Improve the code review process • Create a common language and understanding Secure Software Development: A Security Programmer’s Guide, First Edition

27. Success Breeds Success: The Benefits (continued) • Benefits in the Cube (continued) • Improving the Code Review Process • The Application Guide lays out the where and the how of the developers • It leaves no room for guessing or assuming • Eliminating guesswork saves the developer time and energy from analyzing rudimentary items • Eliminating guesswork also improves the peer review process because every developer knows exactly what reviewers are looking for Secure Software Development: A Security Programmer’s Guide, First Edition

28. Success Breeds Success: The Benefits (continued) • Benefits in the Cube (continued) • We All Speak One Language • Geek speak can be cute and funny, but to people who are not in the know, it can be annoying • Everyday verbiage will begin resembling that of the other developers on your team • Other developers will soon be speaking (and meaning) the same jargon and references Secure Software Development: A Security Programmer’s Guide, First Edition

29. Coming to Terms: Defining the Coding Conventions • Your coding conventions define how the code is written and how it looks • Because the developers will be using these conventions daily, it’s only logical that they lend a hand in defining them • If the group helps decide, it is more likely that the group will cooperate • Application Guide can help foster a secure, repeatable development process Secure Software Development: A Security Programmer’s Guide, First Edition

30. Coming to Terms: Defining the Coding Conventions (continued) • Working It Out: Defining the Look and Feel • Every developer brings creativity and individuality to the overall project • Although uniqueness is good when it comes to designing neat little algorithms to complicated problems, it does not lend itself well to writing code • To develop code that will stand the test of time, one must use secure methods and principles as well as build for diversity Secure Software Development: A Security Programmer’s Guide, First Edition

31. Coming to Terms: Defining the Coding Conventions (continued) • Working It Out: Defining the Look and Feel (continued) • The conventions the team needs to decide on are: • Naming conventions • Tools • Coding conventions Secure Software Development: A Security Programmer’s Guide, First Edition

32. Coming to Terms: Defining the Coding Conventions (continued) • Naming conventions • An example of a naming convention could be a common field, such as a user ID • There could be various variable names that reference this field if the conventions are not defined up front in the Application Guide Secure Software Development: A Security Programmer’s Guide, First Edition

33. Coming to Terms: Defining the Coding Conventions (continued) • Naming conventions (continued) • Object Names: What do you call your software modules and the packages • Names should help categorize the code • Object names are important and need to be meaningful • Then name your objects accordingly • Files: The directory structure of where each file type is stored also needs to be defined • On any given project, there are many file types that make up the application • Having a standard place for all similar file types will make maintenance easier Secure Software Development: A Security Programmer’s Guide, First Edition

34. Coming to Terms: Defining the Coding Conventions (continued) • Tools • How the tools were installed should be documented because the intent of a standard tool set is to have each developer’s entire PC set up the same as the others • Documenting why the tool was chosen is also good information • Which tool to use under certain conditions • Rationales of why chosen over others • By documenting the rationale, you’re saying to the reader, “I looked at alternative methods, but I chose this tool because....” Secure Software Development: A Security Programmer’s Guide, First Edition

35. Coming to Terms: Defining the Coding Conventions (continued) • Tools (continued) • Developers often make design decisions that have a lasting impact on the software • In the end, the Application Guide is all about documenting decision making; why you chose one tool over another • It’s easy to forget why we decided to use a particular design or tool over others • You could be challenged by other developers on different teams; you want to say, “I chose this tool for this task because...” Secure Software Development: A Security Programmer’s Guide, First Edition

36. Coming to Terms: Defining the Coding Conventions (continued) • Coding conventions • Documenting coding conventions will help keep the code uniform • Where to place the brackets in the “If ” statements Secure Software Development: A Security Programmer’s Guide, First Edition

37. Coming to Terms: Defining the Coding Conventions (continued) • Coding conventions (continued) • Documenting Style Sheets • GUIs look the same across all screens • Developers know what to use and where • CONSTANTS • There are always constant values that exist in every program within an application • Using CONSTANTS will enforce the same spelling in all programs • Enforce consistency • Make efficient use of server memory Secure Software Development: A Security Programmer’s Guide, First Edition

38. Coming to Terms: Defining the Coding Conventions (continued) • Coding conventions (continued) • CONSTANTS (continued) • Using CONSTANTS will eliminate the problem of having many variations of the same variable Secure Software Development: A Security Programmer’s Guide, First Edition

39. Coming to Terms: Defining the Coding Conventions (continued) • Bookmarks • Some people can remember URLs and others can’t • Rely on bookmarks and same brain power for other things in life • As a software developer, you will often be helping out your colleagues (and using someone else’s PC) and you will need to recall one of your favorite URLs that tells you the information you need • Keeping all the developers’ bookmarks in sync across all development boxes (computers) is a great way to find information quickly Secure Software Development: A Security Programmer’s Guide, First Edition

40. Coming to Terms: Defining the Coding Conventions (continued) • Code Versioning • Version control software should be a major consideration on any software project • Select a version control software product that allows for third-party plug-ins • Problems that can be eliminated by using code versioning are: • Stepping on code: This occurs when one developer overwrites another’s code • Not deploying all components: This occurs when newer modules are left behind on the developer’s PC and they never make it to the test or production servers. • Not deploying the right version of code: This occurs when a source file goes through multiple versions and the earliest version accidentally gets deployed instead of the latest upgrades Secure Software Development: A Security Programmer’s Guide, First Edition

41. Coming to Terms: Defining the Coding Conventions (continued) • Creating Test Data • Creating test data is another task that developers need to work out and document as a group • How and where do you get valid test data? • Which servers do you test on? • How do you rebuild the development process on the fly? • Programs can be created to automate this task Secure Software Development: A Security Programmer’s Guide, First Edition

42. Coming to Terms: Defining the Coding Conventions (continued) • Governing Standards • The Application Guide governs which standards are used while the code is being built • The three standards the Application Guide (and code) needs to incorporate are as follows • Industry standards: Industry standards set the stage for how code should be developed • Organizational standards: Company standards might include which browser to code for, which code libraries to use • Project standards: Project standards are rules and guidelines that the development team wants to enforce Secure Software Development: A Security Programmer’s Guide, First Edition

43. Coming to Terms: Defining the Coding Conventions (continued) • Agreeing to Disagree • If a person has an issue with the Application Guide (because governing rule is wrong), replace that rule with one that makes sense and continue working as a team • But, if a person has an issue with uniformity and using a standard guideline, I would rather replace the individual • Most developers do not want to conform to certain styles or frameworks because they see it as a way of not growing or learning • Managers and/or team leads need to explain very clearly how the Application Guide is a benefit to the team, other projects, and even the company as a whole Secure Software Development: A Security Programmer’s Guide, First Edition

44. Coming to Terms: Defining the Coding Conventions (continued) • Maintaining the Guide – Common Issues • Rules that are not defined in great detail are sometimes documented with ambiguous statements • Rules that needed to be defined did not get discussed or documented • The rules, standards, or tools that are defined do not apply to the project Secure Software Development: A Security Programmer’s Guide, First Edition

45. Coming to Terms: Defining the Coding Conventions (continued) • Maintaining the Guide (continued) • Whatever the issue is, there should be a process in place that handles changes to this document Secure Software Development: A Security Programmer’s Guide, First Edition

46. Coming to Terms: Defining the Coding Conventions (continued) • Testing the Guide • The Application Guide needs to be tested from time to time • Best and easiest way to test this guide is to have the new developers build their own development PC from this guide using the step-by-step instructions • If something doesn’t work as documented, you have to investigate and figure out what is wrong • Also, if standards and rules are not specific enough, developers will not know exactly how to implement them into their code, which can cause integration issues Secure Software Development: A Security Programmer’s Guide, First Edition

47. Coming to Terms: Defining the Coding Conventions (continued) • Testing the Guide (continued) Secure Software Development: A Security Programmer’s Guide, First Edition

48. Summary • The Application Guide is a tool that provides the blueprint of how the software application is written • The guide serves as a recipe for how to build the developer’s environment on the fly with little or no help so that all developers can build software using the same environment, tools, and standards • It’s common to overlook certain aspects of development that you won’t even realize until you actually sit down to code and realize that you have an issue that needs to be discussed Secure Software Development: A Security Programmer’s Guide, First Edition

49. Summary (continued) • The Application Guide is a living document that should be created by the developers for the developers • The Application Guide will go through different iterations of changes and refinements as the project evolves; this is a natural progression of a living document that improves over time • The Application Guide needs to be tested from time to time to ensure that all the supporting documentation is still accurate Secure Software Development: A Security Programmer’s Guide, First Edition