Security requirements engineering pdf

We remain to be requirements engineering community identifying the convinced that current requirements engineering methods do this. Clark and D. There is a need for [Chun93] L. CAiSE '93, 5th Int. Advanced framework to examine systematically requirements and Information Systems Engineering, Colette Rolland, anti-requirements building on preliminary work, such Francois Bodart, Corine Cauvet Eds.

Springer, Damianou, N. Dulay, E. Lupu and M. Moffett [Moff99] has posited that these [HS97] T. Himdi and R. Project Dissertation. Universite Catholique de Louvain, Belgium, Acknowledgements [McClean94] J. Wiley, We would like to acknowledge the advice and help of our [MF99] J. McDermott and C. Moffett for feedback on an earlier version of the paper. Moffett, E. Anton and J. Sandhu, E. Coyne, H. Feinstaein and C. Secure and Private E-Commerce. Kluwer, This task focuses on understanding the operational context and its relationship to the secure system building.

In order to map the operation environment, the Analyst must perform the following activities:. This activity gives an architectural vision on system security requirements.

Everything users may be able to do into systems needs a good understanding. It is common restricting sensitive operations applying the principle of the least privilege by binding capabilities to roles only when necessary.

The Analyst must perform the following activities:. Although both means the same, the name misuse case seems to be more common and used. They also defined the misusers or mis-actors as the inverse of actor, i. Based on those works and others from Ian Alexander, Alexander, , Alexander, , the requirement Analyst must identify the possible misuse cases using the following activities:. Reviews are good activities for security analysis.

Therefore, although the resistance from Analysts, the review can avoid flaws in the understanding of security requirements. It is recommended that both Analyst and the Security Team make the review. Many times, even after two or more review from Analyst it is common the security team find bad description about the security requirements.

Furthermore, generally the security team has more security skills that requirements Analyst and acts as a third party review. A good practice for review security requirements is the confrontation of analysis between Analyst and the Security Team analysis. This approach can be seen as a trust checking and can avoid misunderstanding. This section summarize the proposed methodology in practical example to perform a Security Analysis.

The Requirements Analyst can describe the application using different tools, such as informal drawings, pictures, sketches etc. The Requirements Analyst also can use high-level risk tables to help the security requirements definition. Exhibit 4 and Exhibit 5 give a macro vision about the security goals, presenting methods that can be used to achieve the protection or mitigation and some tools that may be used to help.

Exhibit 8 shows one misuse case, Spread Malicious Code presented in the Exhibit 7 , using an extensive version. This approach allows the Test Analyst to create test cases for Security Requirements. Capture and treat the security requirements may do a great difference in the final system implementation. Several researchers have been studying and proposed new models to simplify this complex task for the requirements Analysts.

In this work, we presented a discussion about the security into requirements phase. In addition, we showed six tasks method that may facilitate the Analysts activities, illustrated by a practical study case that can be adapted and used by readers. Looking at those activities, we call attention for misuse cases that present a visual form to see the security requirements.

According our studies and experience, they are the best form to elucidate complex security requirements when the most of applications have presented a growing complexity to development. Finally, we have been seen two serious flaws in the security for requirements analysis phase at companies: the lack of security skills for the Requirements Analyst and the negligence with security role into business applications.

The typical objectives of an immunity requirement are to prevent any undesirable programs from destroying or damaging data and applications. This would be a legitimate architectural decision under certain circumstances. The typical objectives of an integrity requirement are to ensure that communications and data can be trusted.

It is insufficient to merely make records; these records must be complete and tamperproof. Note that nonrepudiation requirements may add making the data tamperproof. For example, consider a privacy-oriented eMarketplace application that acts as an intermediary between buyers, merchants, and a credit card authorization processing gateway.

The buyers may not want to provide private personal information e. Note that electronic wallets undermine privacy because they make it easy for buyers to supply private information to merchants.

Instead, the eMarketplace strongly supports privacy by: o Hiding private customer personal information from merchants. The typical objective of a survivability requirement is to ensure that an application or center either fails gracefully or else continues to function possibly in a degraded mode , even though certain components have been intentionally damaged or destroyed.

Survivabilty requirements deal with safeguarding against damage or loss due to intentional malicious threats, whereas robustness requirements deal with safeguarding against unintentional hardware failures, human errors, etc. The typical objectives of physical protection requirements are to ensure that an application or center are protected against the physical damage, destruction, theft, or replacement of hardware, software, or personnel components due to vandalism, sabotage, or terrorism.

Survivability requirements specify continued functioning after an attack, whereas physical protection requirements specify the protection of components.

Physical protection requirements are typically prerequisites for survivability requirements. The typical objective of a system maintenance security requirement is to maintain the levels of security specified in the security requirements during the usage phase. It has identified and defined the different kinds of security requirements, provided good examples that may be copied, and listed guidelines that have proven useful when eliciting, analyzing, specifying, and maintaining security requirements.

On the other hand, CPS involves security risks. Many new attack scenarios are made possible by an unsecured and uncharted physical layer. In… Expand. View on IEEE. Save to Library Save. Create Alert Alert. Share This Paper. Figures, Tables, and Topics from this paper. Citation Type.