Secure software project management comprises the steps that should be taken by software producers in their quest to provide good software to the market. Software production is a very challenging bit in information technology due to the nature of computer software that can be produced to do different functions.
The need to come up with secure projects for software project management has been necessitated by the fact that the software has become a very integral part of the present-day society due to dependence by the society on computers to run different functions.
The use of computers in the day-to-day running of activities has therefore called for the setting up of standards that will guarantee aspects such as security of the software by ensuring that ethical elements of the software production process are followed in an attempt to achieve a sustainable production of better and improved software over time.
This therefore calls for a concerted effort between all stakeholders in the industry as a way of coming up with the best standards that can be followed during software production. With this light in mind, the question, ‘what role should stakeholders play to guarantee software security and hence information assurance?’ forms the basis of argument of this paper.
Project Risk Management
The evident technological advancement is the primary cause of the many incidences of computer insecurity. Hackers have managed to take advantage of the technology to crack into the information banks of other parties without the parties’ consent to perform malicious acts. During software development, several risks are involved, thus calling for all stakeholders to develop strategies to manage the risk for the project to be successful.
Some risks can be easily identified while others may not, or may never be identified because of the complex nature of software development use and management that makes it multifaceted when it comes to managing the risks involved.
Therefore, as highlighted in the next section, the involved parties need to be aware of the role of project risk management in a bid to implement the various risk handling steps in the computer sector as a strategy of guaranteeing security of information that is shared among people and/or organizations. The diagram below shows the steps that they can use for an effective risk management process.
Risk assessment is the first step in managing risks. It involves finding out the possible risks that the given project might face during its development and execution. During this stage, the risk threats to the project are usually highlighted with regard to the purpose that the software is going to serve. Different types of software attract different kinds of interests from players in the industry.
Therefore, software serving very sensitive and lucrative purposes attracts a lot of attention from groups such as hackers (Otniel, 2013, p. 88). Steps can only be taken after the risk has been identified. The next stage involves identifying the risks that can be handled by the persons preparing the software along with the ones that cannot be handled.
The complexity of software development indicates that different software developers have different abilities and hence the reason for continuous emergence of new software by new developers. Developers usually see what they are doing with a different eye relative to other developers. Therefore, the risks that can be identified can easily be solved in this case. There are those risks that are beyond the developers of the programs.
These can only be identified for further research. The solutions for the risks should outweigh the risks because a project that is full of risks is as good as desolate (Otniel, 2013, p. 90). In identifying the risks, standards have been put in place that programmers are supposed to use when working.
Some of the risks identified include technical factors such as the necessary technical abilities to do certain projects, insufficient budget to carry out a project, operational risks that may be due to unforeseen factors, as well as schedule risks (Otniel, Bibu & Brandas, 2012, p 1016). Technical-factor risks emanate from the fact that people working on the project might not be measuring up to the challenge that the risk might provide due to limited technical knowhow.
Some programmers and software developers might be good in one language but not in the other languages. This poses a challenge to the development of the projects. Different methodologies for running projects attract different risk levels, with some methodologies recording a below-medium level while some record an above-medium level as others record a below-medium rank (Brandas, Otniel & Bibu, 2012, p. 153).
While choosing the methodology for executing a software project, the methodology should be compatible with the intended project based on what the programmer wishes to achieve. The final bit about project risk management that should be put in place is coming up with contingency measures that can be employed in case of an emergency.
Software projects face uncertain risks when they are being prepared due to the dynamic nature of software. Thus, there should be a window for employing any contingency measures for any unforeseen risk. This strategy may not take away the risk. Rather, it serves the purpose of minimizing the risk.
Security management of any software is very important especially when the project is a high-value type. Security management is meant to ensure that the security of a software project is functional and one that can achieve its intended purpose of securing the software project. Security management of a software project starts with finding out the requirements of the project (Deven, 2013, p. 35).
Different projects require different security approaches and applications. Therefore, it is prudent to find out the security requirements of the given software so that structures can be put in place to secure the software. Requirements for security management will determine the steps to be taken to ensure the security of the software project.
The design of the software and its accessibility will determine the best security steps that will be put in place. Security measures employed have to be compatible with the design of the software (Allen & Hale, 2009, p.127) because the design determines where the security features lie. To manage the security better, the security system has to be well matched with the software being used.
Security features of software are supposed to be a top secret. They are not supposed to be easily determined by unauthorized persons. Therefore, when setting up the system, very few people should be allowed to know and/or operate the security code because they will be able to make adjustments as administrators. This duty is reserved for persons with permission only.
One way of managing security codes is to restrict the source code of the program so that just one or two people have it. This part is the most important while managing the software because the source code is the key to every part of the software and the whole project. Another important aspect of security management is the interval period for reviewing the security system (Allspau, 2012, p. 49).
The security system being employed should be one that is up-to-date with the latest trends in security features for software across the globe because information technology has made the world a global village and that threats from the most remote and unknown places can cause extensive damage. This therefore calls for the employment of a system that has been tested and declared good compared to the existing threats.
No system can be the best because malicious players in the industry usually work hard to break the tightest security, thus setting the bar higher and higher. The system should be one that can be periodically evaluated to ensure that it is still relevant with the latest technological changes, which are due to the dynamic nature of the information technology industry (Allspau, 2012, p. 49).
A security system being used on the software should not be permanent. Rather, it should be disposed the moment it becomes obsolete. Therefore, it is advisable to come up with a security system that be upgraded over a period. Security management will therefore require someone to be tasked with taking care of the security system of the project.
In this case, the person will be giving support services as long as the project runs (Deven, 2013, p. 36). Support services will entail taking observations on the security system from other users and servicing the security set up to conform to the security demands of the industry as well as those of clients.
Secure Configuration Management
Management of configurations securely calls for a systematic set up of structures from the time the software is being produced to the time it will be used. Configuration settings and alterations should be limited to few people who are entrusted with the software (Parminder & Hardeep, 2012, p. 262). This group should be the administrators of the system who should have the authority to alter configurations.
Configurations should be secured where and when it is necessary. The process should not act as a hindrance to the proper functioning of the software because rigid configurations can lead to a waste of time as individuals waits for authority to change any settings that are necessary for their work.
To secure configurations further, the system should have passwords for all individuals using them so that unauthorized persons may not have access to the system (Thanjaivadiel & Singh, 2012, p. 1494). This step has to come with a history log that will indicate the time and period of each log in identity so that any malicious log in can be identified with immediate effect.
Configurations for a system are usually better when they are done to the specifications of the client being served. Therefore, it will be prudent for the configurations to be done in such a way that they are easy to navigate while working with them. When the software is being produced, the programmer should secure every step of the design to make sure that every step that has to be changed will have to be effected using a password (Priyanka, 2013, p. 603).
All configurations should be made according to the principles of the industry so that they conform to the set standards. System configuration should be done when the software is still being prepared. They should also be adjustable when the software is in use. Configurations should be secured against malicious attacks (from hackers and other software) because such groups form the greatest threat to all software that is being produced.
Accordingly, as part of the configuration, the system should have an antivirus installed therein. Configuration settings should be secured further by creating automatic security features that would work on their own without necessarily being prompted (Parminder & Hardeep, 2012, p. 264). This erases the need for an individual having to activate them all the time he or she need to do so.
Secure configurations that activate on their own provide better security in instances where one forgets to activate them most of the times. Thus, one will always work with the confidence that the configurations are safe from interference. To secure the system against arbitrary changes that might be malicious as well, the system should be configured in such a way that it highlights any changes that might have occurred to the set up system (Priyanka, 2013, p. 604).
Many hackers usually use loopholes in the configurations of systems to insert their own commands that will secretly allow them access to whatever they want. A log page or message that reports any changes will enable administrators to be alerted on the changes while at the same time showing them any other activities that have been going on with the changes.
Such alerts will enable administrators of the system to make new changes in terms of the security of the system. They will also enable them know the vulnerabilities the system faces for further action. Very vulnerable configurations should be discarded because they will simply be a conduit for exploitation by malicious activities.
Software Quality Assurance and Security
The quality of software depends on many different factors that when evaluated will determine if the software is good or not. Quality assurance of software is therefore a very challenging issue because of the dynamic nature of software, which keeps on changing day-by-day (Ankur, 2010, p. 2874).
The life cycle of a software product can never be assured as long as programmers are working round the clock to come up with new software. In fact, programs such as the iSEC’s SecurityQA Program have come in to offer security services. The diagram below shows the services.
Source: (Ankur, 2010)
The best assurance that the industry can offer is a standard that should be applied when developing any software program. This goal is achieved through the input of different players in the field. Quality assurance and security are usually attained when the government and the private sector groups come together to set up standards for system development (Terek, 1988, p. 397).
The challenge with software development is that it is something that can only be controlled in a limited manner because anybody with the knowledge can come up with software of his or her choice and put it to use without seeking authority. Due to the rise in criminal activities especially on the internet, standards and laws have been put in place to ensure that software buyers are protected largely from unscrupulous players.
Both the government and the private sector usually set the quality of software because the private sector is the largest consumer of software other than the government (Terek, 1988, p. 398). Global trends in software development advise on the steps that should be taken to ensure that the software developed falls within certain standards.
Software developers and buyers will therefore have the duty to find out whether it meets certain features that fall within the definition of quality and standards before they develop or buy the software. Ethical standards are set to ensure that any software made is ethically fit for the market (Borislav, 2012, p. 1230). What ethics tries to erase is the mischief that can be played by developers when they try to still control of software they have already sold you.
Some developers may insert malicious codes in the software since it allows them to access it when on the internet. This act is wrong and unlawful because they will be intruding on someone’s privacy. Quality assurance standards keep on changing with time as new developments happen in the industry and hence the need for industry’s main players to review them on a regular basis (Borislav, 2012, p. 1234).
For instance, the major worldwide internet service players have come up with a database that identifies and notes any emerging malicious viruses and software. They therefore highlight them, block them, and put them in their database so that other players can check with them to find out the latest threats to their work (Ankur, 2010, p. 2876).
Allen, J., & Hale, R. (2009). Improved Security Through Information Security Governance. Communication of the ACM, 52(1), 126-129.
Allspau, J. (2012). Fault Injection in Production. Communications of the ACM, 55(10), 48-52.
Ankur, P. (2010). A Framework Based Approach or Reliability & Quality Assurance of Safety-Critical Software. International Journal on Computer Science and Engineering, 1(1), 2874-2879.
Borislav, N. (2012). Software Quarterly Assurance Economics. Information & Software Technology, 54(11), 1229-1238.
Brandas, C., Otniel, D., & Bibu, N. (2012). Study on Risk Approaches in Software Development Projects. Informatica Economica, 16(3), 148-157.
Deven, D. (2013). Beyond Location: Data Security in the 21st Century. Communication of the ACM, 56(1), 34-36.
Otniel, D. (2013). The Role and the Effects of Risk Management in IT Projects Success. Informatica Economica, 17(1), 86-98.
Otniel, D., Bibu, N., & Brandas, C. (2012). Risk Management Approaches and Practices in IT Projects. Annals of the University of Oradea, Economic Sciences Series, 21(1), 1014-1020.
Parminder, K., & Hardeep, S. (2012). Configuration management Issues in Software Process Management. American Journal of Engineering and Applied Science, 5(3), 261-265.
Priyanka, G. (2013). Configuration Management and Change Management. International Journal of Advances in Engineering & Technology, 6(2), 601-605.
Terek, A. (1988). The Economics of Software Quality Assurance: A Simulation Based Case Study. MIS Quarterly, 12(3), 395-411.
Thanjaivadiel, S., & Singh, J. (2012). WWDC Server Software Inventory Management and Automation. International Journal on Computer Science and Engineering, 4(8), 1493-1497.