The waterfall model has fixed sequences for developing software for organizations. The model assumes that the process of developing software should flow steadily through several phases until the last phase. The development of software assumes a sequential manner in this model. One cannot proceed to the next phase until the current phase is complete.
It has discrete phases, which do not allow developers to move randomly across different phases. It is important to note that the developer must ensure product security assurance at all phases of the life cycle of the product when using the waterfall model. The waterfall model is useful for developing complex applications for large organizations like banks.
The waterfall model saves time in large projects. Engineers spend much time at the early phase of the project to ensure that every requirement and design phases are completely correct. Thus, it saves time later. In large projects, the developer must define both the starting point and the end of the project. Milestone is useful for showing the project progress.
Moreover, the need to define requirements and design ensures that the project remains on schedule and meets the customer’s expectations. The linear nature of the model provides simplicity in structure, which is logical, discrete, and simple to comprehend. Thus, customers can understand various stages of the product development.
The waterfall model provides stability for large organizations, which require stable, trusted, and secure products because the product’s requirements are not likely to change for a long time. Moreover, the model is suitable for large organizations because the developer and the customer can determine and evaluate any possible risks before the implementation stage.
On the other hand, the waterfall model consumes much time in large projects. For instance, the developer must get requirements and the design right before the development starts. The problem usually arises when clients do not understand what they want. This leads to frequent changes in the design. Moreover, some clients may insist on a prototype before making a decision on required requirements.
It is also difficult to solve challenges that occur during the implementation stage. There might be serious unforeseen challenges in software development, which the model may not account for during developmental phases (Bishop, 2003). The waterfall model also offers advantages to mid-market sized firms like Burger King, which has nationwide outlets. These outlets operate in a networked environment.
The product for such a customer is simple to design and use. The stringency of the model makes each stage easy to “manage because of definite and defined deliverables” (Sommerville, 2006). If the developer understands all the requirements, then the waterfall model works well for such medium projects. When the engineer and the client identify all requirements and the design, then the model can enhance superiority and security of the product.
The model allows the developer to identify errors and correct them before proceeding to the next phase. Thus, the testing phase may lack errors. It also eliminates challenges of tracking problems during the testing phase. The waterfall model is simple to follow. Thus, developers can easily train users on maintenance (Hoffer, George and Valacich, 2004).
The model also has cons for small projects. Several tests of a prototype can lead to increments in costs and time spent on building a product. Engineers spend time to build prototypes, which the customer may change frequently. The model does not account for a system upgrade for small organizations, which may expand their operations or introduce new units to the business.
Thus, the model cannot serve several practical projects (Johnson, 2011). Generally, one must recognize that product development for both small and large organizations is not a linear process as the waterfall model depicts. In some cases, there might be disconnects between actual needs of the organization and the developed product.
This may lead to challenges of imposed conformity during software implementation. Thus, an organization may end up with an imposed product, which can be the start of the project failure.
“The issue of binding assurance requirements to functional requirements versus treating them as mutually exclusive sets has been debated over the years.” Binding assurance requirements are mandatory assurance for product security. Developers should include binding assurance requirements at the design phase of a product development.
Trimmer, Schou, and Parker have proposed early binding assurance at every stage of the product development. Thus, it is important to combine security with objects and functions prior to developing any code (Trimmer, Schou and Parker, 2007). One must assess the product for “binding and functional assurance requirements” (Roback, 2000).
However, users must consider their requirements and choose the best products for their operations. Users and developers must note that concerns with functional requirements may overshadow other system security requirements (Sommerville, 2006). Thus, integrating both binding assurance requirements and functional requirements would guarantee that both functional and binding assurance requirements are present at every stage of the system development.
Edward Roback notes that assurance in every single part of the product enhances security assurance of a system, but this approach does not guarantee system assurance and security of the system (Roback, 2000). For trusted products, a combination of binding assurance requirements and functional requirements would guarantee system security and system functionality.
In other words, binding assurance requirements and functional requirements must be together in order to complement each other as they serve their intended purposes (Wiegers, 2003; Stellman and Greene, 2005; Bourque and Dupuis, 2004).
In the context of the Common Criteria (CC) methodology, analyze the benefits and drawbacks of binding assurance requirements to functional requirements and vice-versa. The Common Criteria (CC) has “seven predefined assurance packages, known as Evaluation Assurance Levels (EALs)” (Roback, 2000). Thus, the major focus of the CC is assurance of product security.
While some assurance requirements may be common, the CC has the flexibility to allow customers and developers to state their own unique situations to meet their assurance needs. Hence, the predefined EALs may not be mandatory for developers and users. The CC puts emphasis on EALs for the system security. In this context, the business need of the customer defines EALs for necessary assurance conditions for the product evaluation (Common Criteria Project Sponsoring Organisations, 1999).
The CC recognizes that it is difficult to define functional requirements. Moreover, customers have shown that their functional requirements have evolved with time. It also considers customer’s needs when defining functional requirements of a product. Thus, functional requirements within the CC methodology define how product developers must meet assurance features.
The CC assumes that binding assurance requirements are already in the product, but only evaluates them where there might be a conflict. In this context, the CC asserts that developers should adopt actions, which lessen chances of software vulnerabilities and subsequent damages due to vulnerabilities.
Moreover, product development phases should provide methods of identifying and mitigating identified threats. One major challenge is that predefined binding assurance requirements may result in challenges because of difference in interpretation of language used.
For the CC methodology which is preferable and why? From the CC methodology, it is important to evaluate functional requirements of software. The CC provides assurance from the result of the product evaluation for users to trust such products. Evaluation can only be effective through testing functional requirements of products.
Thus, the CC methodology insists on evaluating software validity, and it focuses on the scope, depth, and rigor of the product. It is important for users to obtain software with the required functional requirements and performance. In this context, software performance must account for reliability and dependability, which must relate with security requirements.
The CC acts as a third party for testing software for users and developers. Thus, it is an important way of gaining customer confidence by guarantying functional requirements. However, users must note that an evaluated product may not necessarily meet their business needs because of possible differences in appropriate functional and assurance requirements.
Hence, customer must define their needs and consider products, which will meet their business needs. Martignoni and colleagues note that the current PC-based and Web-based platforms do not offer adequate security for data, which users can access (Martignoni et al., 2012). They observe that the presence of a threat in any part of the client’s software makes data prone to attacks, which compromise integrity and confidentiality of such data.
The major reason for ensuring computer security is to block unauthorized access to data and prevent unauthorized users from changing or knowing about sensitive information. Current systems are vulnerable because they do not provide adequate protection to end users. They rely on divided applications, which have several tiers. Each tier presents a point of vulnerability to attackers.
They note that the “most vulnerable points to attacks are tiers at the client’s software stack on personal computers” (Martignoni et al., 2012). Martignoni and colleagues propose a new architecture called Cloud Terminal as the best solution for the software stack vulnerability for users’ personal computers. They show that the user’s side mainly focuses providing applications for obtaining information, but fails to conduct intensive computation for the system security.
They propose that the best solution would be to move some specific applications from areas, which are difficult to protect from the client’s side. As a result, they note that the end user can rely on a secure I/O path in order to gain access to sensitive information from the cloud application. Martignoni and colleagues aim to develop an application that would be able to reduce security threats, but would also be easy to adopt and use.
The researchers’ Cloud Terminal solution seeks to achieve the following goals. First, the application would work on any existing PC with its compromised OS. Thus, the end user will not “make any changes to the system” (Martignoni et al., 2012). Second, the Cloud Terminal would not “rely on the trust of the host OS” (Martignoni et al., 2012). Third, the application would be able to show its “existence to all users and guard the system against phishing and spoofing” (Martignoni et al., 2012).
Fourth, the solution would provide support to several sensitive modules. Finally, the solution would use a small TCB (23 KLOC). The solution would operate on the standard PC hardware as it offers a secure platform to users. The researchers note that the Cloud Terminal would be useful as “a responsive interface to applications like banking, e-mail, and document editing” (Martignoni et al., 2012). Moreover, the solution can reduce the cost of banking transactions for customers.
The impact this research will have on the future of Formal Verification of trusted operating systems and trusted software in general. Generally, this research provides a platform for further developments of secure and trusted solutions for end users. It shows that developers are willing to address data security concerns among users.
As a result, researchers have focused on new platforms like cloud computing, which may be vulnerable to attacks (McCune, Perrig and Reiter, 2006). Thus, formal verification must also focus on software for new applications. The proposed Cloud Terminal solution clearly indicates the goals and threat model.
It shows that the solution would be effective in addressing the identified security concerns of users. Thus, formal verification processes shall evaluate the stated goals of proposed solutions. The process would ensure that new solutions must capture security concerns of users and meet their expectations. Validation processes must also evaluate security effects when requirements change from one platform to another (Drusinsky, Michael and Shing, 2008).
The study also shows that future solution would provide several benefits to end users. For instance, it shows that the use of Cloud Terminal would be cost-effective because users do not have to purchase new hardware or change their current OS. In addition, the cost of conducting transactions will also decline significantly. At the same time, new solutions shall able to meet specified functional security requirements of a system (Grembi, 2008; Charles and Turner, 2004).
References
Bishop, M. (2003). Computer Security: Art and Science. Boston: Addison-Wesley.
Bourque, P. and Dupuis, R. (2004). SWEBOK: Guide to the Software Engineering Body of Knowledge. Los Alamitos, CA: IEEE CS Press.
Charles, P. and Turner, P. (2004). Capabilities Based Acquisition: From Theory to Reality. CHIPS, 22(3), 38–39.
Common Criteria Project Sponsoring Organisations. (1999). Common Criteria for Information Technology Security Evaluation. Web.
Drusinsky, D., Michael, J., and Shing, M. (2008). A Visual Tradeoff Space for Formal Verification and Validation Techniques. IEEE Systems Journal, 2(4), 513–519.
Grembi, J. (2008). Secure Software Development: A Security Programmer’s Guide. Pennsylvania: Thomson Learning College.
Hoffer, A., George, J., and Valacich, S. (2004). Modern Systems Analysis and Design (4th ed.). Upper Saddle River, NJ: Prentice-Hall.
Johnson, M. (22011). pplication Management: What you Need to Know For IT Operations Management. Brisbane: Emereo Pty Limited.
Martignoni, L., Poosankam, P., Zaharia, M., Han, J., McCamant, S., Song, D.,…Stoica, I. (2012). Cloud Terminal: Secure Access to Sensitive Applications from Untrusted Systems. Web.
McCune, J., Perrig, A., and Reiter, M. (2006). Bump in the Ether: A Framework for Securing Sensitive User Input. Annual Tech, 185-1998.
Roback, E. (2000). Computer Security: Guidelines to Federal Organizations on Security Assurance and Acquisition/Use of Tested/Evaluated Products. Washington, DC: National Institute of Standards and Technology.
Sommerville, I. (2006). Software Engineering (8th ed.). Boston: Addison Wesley.
Stellman, A., and Greene, J. (2005). Applied Software Project Management. Cambridge, MA: O’Reilly Media.
Trimmer, K., Schou, C., and Parker, K. (2007). Enforcing Early Implementation of Information Assurance Precepts throughout the Design Phase. Journal of Informatics Education Research, 9(1), 95-120.
Wiegers, K. (2003). Software Requirements (2nd.). Redmond: Microsoft Press.