Security requirements can be elaborated as any procedures and devices used to in a specific system to provide protection. They can, however, be discussed in the context of well-established implementation mechanisms such as password protection, firewalls and virus detection tools.
There are a number of approaches to the study of security requirements engineering, for instance, the elicitation method is likely to provide a framework for ordinary functional requirements which are more often than not oriented towards the security requirements however using the elicitation method can give rise to a system which is less exposed to security exposures if such is done in a systematic way (Araujo, 3).
Security system Models
An objective evaluation into the operation of the systems can help validate a particular product to ensure that it meets certain criteria of security requirements. For instance, the System Quality Requirements Engineering popularly referred to as (SQUARE) developed at the Camegie Mellon University’s CyLab proposes a way of eliciting, categorizing and prioritizing security requirements for information technology systems and applications.
According to Anderson (1002), the primary concept in the SQUARE model is to establish solid security principles in the initial stages of the development life cycle. In the same capacity, documentation and analysis using the same model ensure that security requirement changes are incorporated back into the system, easily.
The Comprehensive, Lightweight Application Security Process commonly known as CLASP is yet another model used to aid software-related developing teams to design activity –driven, and role-based components to secure the systems during the initial stages of the new –start and developing software life cycles.
This model actually endeavors to provide a well ordered, repeatable and assessable elicitation approach. The amount of resources a company is willing to devote to software security mitigation for the applications greatly affects the kind of security requirement procedures developed especially in software engineering companies among other security-based business ventures (Anderson, 1030).
Implementation of a security system
On several occasions if you have a number of security requirements well listed it is necessary to prioritize them in the order they are expected to be implemented.
Lee 350 further explains that the order of implementation in various companies or organizations greatly varies because some companies or organizations will choose to implement the least costly first while some will prefer to go for the easiest to implement without much regard to the importance and the predisposition of the system since each system is likely to have unique features and procedures.
It is, however, well established that most organizations ignore the security-enhanced software development lifecycle despite the fact that it is very integral in the security requirement engineering process.
The developers assume that this should be performed during the architectural and designing stages or rather at the implementation stage since it is viewed as technical and complex.
This assumption is likely to present a challenge to the functioning of the system because experienced software experts can attest to the fact that any software that is not well-vetted or does not have its requirements elicited, enumerated and well documented will fall below standards in any assessment it is subjected to. The problem is usually caused by lack of a specific target on the part of the developers and the lack of well-set benchmarks together with validation procedures on the side of quality assurance (Anderson, 1034).
The security requirement engineering is a vast and critical subject in all formally set up organization; it is one thing that cannot be just dismissed as useless or of less value the challenge is that most of these organizations seem to embrace an individualized approach to such issues.
The more often than not preoccupy their minds with the functional requirements while ignoring the non-functional requirements commonly marked as N/A and therefore they are set apart as de facto requirements which should be too obvious to be documented.
Alternatively, lack of awareness and information on the writer of the requirements presents a more significant problem. A critical analysis of the non-formal requirements establishes the technical background for which the required vital lengths, rotation parameters, algorithm, cipher code and encryption are based.
As established by Haley (137), to define the above list will require a detailed understanding of the mechanism around cryptography. In that case, the information concerning the requirement may not be in the job description of a business analyst and if that be the case very little attention will be attached to the provision of such security measures or procedures within the system in question.
Security requirements categories
The first step towards a successful security system is to identify the drivers for security requirement that will influence development. For instance, the drivers can be segmented upon four categories depending on the setup.
The first will pass as regulatory compliance which will detail specific requirements as mandated by government agencies based on the scope and legal environment under which the company operates. The second sub-category will concern itself with industrial regulations and standards again based on the line of operation.
This part will deal with issues like standardization which encompasses bodies like ISO and financial services. The third and fourth sub-categories will deal with company policies such as; privacy policies, coding standards, patching policies, data classification policies, information security policies, export control, open-source usage and acceptable use policies. Security features such as authentication and authorization models which are very specific to management will fall in the fourth rank (Haley, 140).
Most organization using the online kind of data handling need to strategize on how to provide software security training and building policies like language coding standards to assist the people involved in developing to quickly deal with the challenges as well as curb the introduction of future vulnerabilities.
The security issue should be given a very holistic approach involving all the concern parties and that includes; effective personnel, well-set processes, and up to date technology. Universally, however, security requirements engineering is linked with enhanced software development life cycle. This is usually the case, especially where the system is expected to aid in efficient security levels of an organization’s applications (Lee, 350).
Conclusion
It is also obvious that the rate at which technology is advancing is tremendous and hence is the development of security threats across the established systems. The process of security requirement engineering should be continuous and dynamic in order to deal effectively to the ever-emerging issues concerning the security.
In conclusion, security requirement engineering emerges as one of the most integral and sensitive components in any given organization, therefore, specialized attention and heavy investment by the concern companies will help revolutionize as well as take the subject to another level.
Failure to do such will unnecessarily predispose the systems to unnecessary security threats which are likely to impair the proper and effective functioning of the company concern. It is extremely essential to invest in security requirement engineering as a tool to avoiding mishaps that can otherwise be easily remedied at the initial development stages. Proper and timely planning is also requisite to enhancing the development and sustenance of a workable security requirement engineering process (Anderson, 1036).
Works Cited
Araujo, Robert. Security Requirements Engineering- A Road Map: Rudolph Araujo of Foundstone, 2007.
Anderson, Jared R. Security Engineering: A guide to building dependable distributed systems. Wiley and Sons, Ed 2, 2008, Vol. 1000-1040.
Haley, et al . Security Requirements Engineering: A Framework for Representation and Analysis. ACM press, 2008, Vol. 34 pp. 133-153.
Lee, Lee J. and Lee, Z. Integrating Software Lifecycle Process Standards with Security Engineering: Computers and Security. 2002, Vol 21. pp. 345-355.