security to successfully manage the development of secure software. ... Any project manager responsible for the development of software applications must ...
Developing Secure Software – A Project Manager’s Approach Juan R. Reyes – July 21st, 2014
Abstract Software development project managers must be cognizant of the technological, regulatory, and human dynamics involved in the creation of secure software. They must develop and apply a broad understanding of security to successfully manage the development of secure software. This paper does not delve into the minutiae level of secure coding practices but is intended to provide thought points to the project manager at an overview level. The meaning of secure software is established, along with recommendations on how to start the secure software development process, and how to verify that the software is secure once it is ready for deployment in the customer’s environment.
Developing Secure Software Any project manager responsible for the development of software applications must consider security in the final software product in addition to the features and functionality dictated by customer requirements. In fact, it is best that security be considered a critical feature and function with importance equal to the most critical user requirements. Software coded with best security practices is not just a product of a “we’re conscientious in our coding practices” mentality by the development team. Security within software is often mandated by regulatory compliance rules - it is becoming more and more of a requirement rather than an option. The reality is that security must be considered and designed into the application from day one of feasibility and pre-planning stages and throughout the design, testing, and implementation phases instead of being merely assessed during the post-implementation and regular use phases. It is preferable that the development team find security flaws during pre-implementation rather than to have hackers discover the security flaws post-implementation. The variety and number of software security flaws out in the world is staggering. In actuality, software security flaws have brought on the existence of many security defense products such as antivirus and malware detection and removal applications, proxy servers, IDS/IPS (intrusion detection systems/intrusion prevention systems), and application firewalls. Security flaws exist in a practically every type of software product including operating systems, web browsers, productivity suites, network services, etc. A conscientious and diligent software development project manager will put forth a full effort to produce the most functional and most secure software system for the customer’s use. This paper lays out some general methodologies a program manager can employ to achieve this goal.
What Does Security in Software Development Mean? A software system can be considered a victim of its own functionality. Its threat vectors are typically the unintended byproducts of the core utilities that the software provides. A bookkeeping data entry application is designed with fields that allow clerks to enter numeric values. Without the proper software validity checks in these fields, a user with malicious intent could enter invalid characters such as the “/” or “@” symbols to determine if a vulnerability can be exposed. The software may not be written to handle these invalid characters gracefully with a NULL action response. If no graceful response is written into the code for invalid characters, the hacker could exploit the system due to the weakness or complete lack of built-in software controls and gain administrator access to the bookkeeping system and wreak all manner of havoc through data manipulation and/or theft that could put a business out of business. By enforcing a simple validity check on characters entered into the field in the software design that enforces a numbers only policy, the impact of such a threat is eliminated. Another common software design flaw occurs with the buffer overflow exploit. Many software applications take data input into a field such as the data entry example previously mentioned. After data is entered into a field, software will stage the data in a holding area before processing. This holding area is called a buffer. Buffer overflow, as the name implies, is forcing too much data into the buffers so that there is an overflow of data. The overflow of data can cause several outcomes depending on the individual system. The buffer overflow can crash the system causing a denial of service that takes out
the availability of an application. This can result in a loss of revenue for a company. It can also cause a loss of data and/or data processing that will impact system integrity. Buffer overflows, again depending on the individual system, can also enable a hacker to take administrative control of a system to steal or manipulate data for nefarious purposes. Much like the character validity check in the first example, the problem is simply addressed with a control coded in that limits the number of characters that can be entered into a front-end field which will in turn control the number of characters that get directed to the buffers. The buffers then cannot be overflowed. As has been stated already, the diversity and multitude of software security flaws out in the world is of tremendous proportion. The aforementioned are but two examples for the sake of this paper. While coding practices are mature now in the year 2014 and these two issues are not as common as they once were, there are still software applications that get implemented with these vulnerabilities. The root causes can be varied - inexperienced software programmers, development management that is less than diligent, and ignorance of the potential vulnerabilities are among the reasons that software gets shipped with vulnerabilities.
Where Does the Project Manager Start? Without exception, all software functionality requirements must be actively ascertained from the customer at the beginning of the planning stages and throughout the duration of the development stage and into the implementation stage. The key takeaway is “actively ascertained from the customer” and not so much “actively ascertained by the customer.” A conscientious and professional development project manager is going to have the customer’s best interests in mind and may need to be actively determining the security requirements on behalf of the customer instead of passively waiting for the customer to lay out the comprehensive security needs. Of course, the project manager will have scope parameters to think about as well as liability considerations to consider. The project manager may very well have to suggest that the project charter be altered after project kick-off so that it includes any changes to address security that come up during the design, testing, and implementation phases. As for legal issues and liability borders, the project manager should rely on the appropriate legal advice when attempting to enact due diligence in the security design of the software for the paying customer. The security aspect of software design can certainly entail legal issues in terms of who is liable for the design. One argument is that the customer is obligated to provide the detailed specifications to include the security requirements and that the development firm is not under any requirement to layout specifications since the development firm will not be the intended user of the system. While that may sound convenient to many of the development firms in the industry, the reality is that the development firm is going to at some point and to some degree guide the customer in the specification determination process. The implications for not doing so include the loss of professional reputation as developers. The “stink” of being the firm that developed a system that was compromised by hackers and resulted in major losses in revenue and reputation for a customer will be the smell that potential customers whiff when the development firm comes near to solicit future projects. Loss of reputation begets loss of business. Loss of business begets bankruptcy. It behooves software development firms to have the best interests of their customers in mind at all times - even if contract clauses do not cover specific aspects of the best interests. A development project manager needs to get to know the customer to determine their needs even when, or especially when, the customer is not able for some reason or another to articulate a full and comprehensive set of requirements. The customer may be an exuberant entrepreneurial type who does not think in terms of software functionality requirements and security best practices in coding.
This is when and where the project manager has to initiate and maintain meaningful communication with the customer. If there is a person who acts as a technical interface on behalf of the entrepreneur, that may facilitate the solidification of requirements. If not, the project manager will need to play a more active role in defining requirements. Of course, the project manager does need to be under the guidance of competent legal advisors if the project manager finds himself or herself in such a situation. What does the software need to do? If payment processing is a requirement, the project manager needs to develop an understanding of which regulations that the customer must comply with even if the customer does not know themselves. Perhaps there are credit cards involved. The project manager should research what regulations might exist for the processing of payment cards. The PCI-DSS (Payment Card Industry Data Security Standard) standard provides general guidelines on secure software design. Perhaps the customer is in some way providing services to government clients. This could mean that their applications must adhere to certain government standards such as FISMA (Federal Information Security Management Act) or FIPS (Federal Information Processing Standard) in order to do business with the government. Will a small startup looking to be a contractor for hospitals and handle medical records know that their applications must conform to HIPAA (Health Insurance Portability and Accountability Act) requirements? These are explicit and implicit business requirements that the project manager may find themselves determining on behalf of the customer if the customer is unable to lay these out in the specifications list. Even if the customer is not subject to comply with any regulations, the project manager should strongly consider using any applicable regulations to provide a design framework that will enhance security. The project manager may need to sell the customer on the idea of using a security design framework if the customer is looking for quick turnaround on a useable product. The project manager may need to get the customer to think both short-term operationally and long-term strategically so that the customer can see the benefit of adhering to a secure framework design. Aside from regulation frameworks, the project manager should also seek out software design best practice guidelines and incorporate them at every applicable stage of development.
How is Security Verified? Security testing must be performed regularly throughout the lifecycle of the product - from the early development stages through to the time that the software is retired from service. Security test plans, along with the usual user functionality test plans, can start to be devised as soon as the user requirements are defined. Security test plans must evolve and adapt for adequacy if any functionality and specific security requirements change during any of the lifecycle phases. Test plans need to incorporate security and functionality testing as being symbiotic of each other. A common byproduct of security within a system is a hit to system performance. Added security equates to added validity checks and more lines of code that equate to more processing that can negatively impact system performance. A common mantra in the world of security professionals is security vs. performance - which does the user want? All testing must give consideration to this reality and plan accordingly in terms of efficacy of plans and scheduling. Testing of security, just like testing of functionality, must be performed by a separate entity than the development team. This is to ensure objective testing and avoid any conflicts of interest that might potentially manifest into a security flaw in the system. An effective testing method during the pre-implementation phases is to outsource to a third party. As long as the outsourcing is done in a legitimate manner, the third party will be more likely to give objective test results and not be under the
sway of internal politics that an in-house QA team would. The third party testing house will give another set of eyes onto the product away from the “group think” of the development firm. Security testing cannot stop once the software is implemented by the customer. A development firm may or may not be keen on the idea of finding flaws in the software they developed once it has been rolled out and paid for - however, a conscientious firm concerned about its reputation and longevity will actively test its software and release patches that address any security weaknesses. Post-implementation testing can become the responsibility of the customer as well as the development firm. Customers will either employ in-house penetration tests or contract out a third-party to perform vulnerability assessments on a regular basis. In some cases where critical applications are in play, both in-house and outsourced approaches are employed to ensure comprehensiveness. A development firm can employ both methods as well even after their customer has paid for and implemented the software. It comes down to the firm seeking continuous improvement and optimization in their coding practices to deliver the best products to their customers and achieve competitive advantage.
In Closing... Software has enabled so many things in modern life. Pen and paper transactions that took weeks to complete from start to finish are now done in real-time. The Library of Congress is accessible to anyone with an Internet connection. As with all things in this world that bring benefits, there will be inherent risks and software exemplifies this in all of its glorious utility. Security shortcomings are risks that go hand in hand with the many functional benefits provided by software. The development of secure software entails the incorporation of secure best practice methodologies along with the finding and resolving of security flaws before hackers find and exploit them. The development project manager must do his or her part to champion the cause in the interest of the customer, the honor of the profession, and for the sake of his or her own career.
References Cannon, D. L. (2011). CISA Certified Information Systems Auditor Study Guide (3rd ed.) New York: Sybex Harris, S. (2010). CISSP All-in-One Exam Guide (5th ed.) New York: McGraw-Hill Osborne Media
