Engineering Security Requirement

1. Engineering Security Requirement Research Paper Published By: Donald G. Firesmith Presentation Prepared By: SohabMihssen Mitul Shah Gaurangbhai Shah AnantvirBrar MansiAlsmarah

2. WHAT IS REQUIREMENT • An established need justifying Which are necessary attribute, capability, characteristic or quality of a system in order for it to have value and utility to a user • Requirement phase is very important in any project development cycle • Why we need? • As we already studied roughly 42% of project failure is due to the requirements – gathering, documentation and management • So here Key component is Requirement • Types: • Functional Requirement • Data Requirement • Quality Requirement • Interface Requirement

3. SECURITY REQUIREMENT(why we need it) • The quality representing the degree to which a system or component prevents, detects, reacts, and adapts to malicious harm to valuable assets caused by attackers • Most requirements engineers are poorly trained to elicit, analyze, specify, and manage such quality requirements as interoperability, operational availability, performance, portability, reliability, and usability, many are at a loss when it comes to security requirements • This article will help you distinguish between security requirements and the mechanisms for achieving them, and will provide you with good examples of each type of security requirement

4. GUIDELINES • Security Policy • Misuse Cases • • Threats vs. Goals • • Requirements vs. Architectural Mechanisms and Design Decisions • • Validating Security Requirements

5. REQUIREMENTS • To meet the objectives, we will briefly address each of the following Corresponding kinds of security requirements: • • Identification Requirements • • Authentication Requirements • • Authorization Requirements • • Immunity Requirements • • Integrity Requirements • • Intrusion Detection Requirements • • Nonrepudiation Requirements • • Privacy Requirements • • Security Auditing Requirements • • Survivability Requirements • • Physical Protection Requirements • • System Maintenance Security Requirements

6. IDENTIFICATION REQUIREMENTS • Objectives: • Ensure that all of the important externals are identified before they are allowed access • Examples: • The application will identify all its human user’s before allowing them to use its capabilities. • A Data Center Facility will identify all personnel before allowing them to enter premises.

7. IDENTIFICATION REQUIREMENTS Guidelines: • Necessary prerequisites for Authentication Requirements. • consistent with privacy requirements, which may require the anonymity of users. • Used to implement : • Who you say you are: • What you have: • Who you are: Measurements: • Minimum number(percentage) of valid users identified • Maximum number(percentage) invalid users identified

8. AUTHENTICATION REQUIREMENTS Objectives : • To verify the identity of its user’s • Avoid compromising security to an impostor. Examples: • verify the identity of all its of its user’s before allowing them to update their user information. • verify the identity of its user’s before accepting a credit card payment from that user

9. AUTHENTICATION REQUIREMENTS Guidelines: • Authentication depends on identification. • prerequisites for authorization requirements. • Used to implement : • Who you say you are: • What you have: • Who you are: Measurements • Minimum number (percentage) of valid identities authenticated. • Maximum number (percentage) of invalid identities authenticated.

10. AUTHORIZATION REQUIREMENTS • Objectives : • To authorize specific authenticated externals to access specific services or information. • Ensure that specific authenticated externals can access specific services or information • Examples: • not allowing any customer to access any account information • not allowing customer service agents to access the credit card information of customers.

11. AUTHORIZATION REQUIREMENTS Guidelines: • depends on both identification and authentication. • used to implement : • Hardware electronic keys Measurements: • Minimum number (percentage) of authenticated externals authorized. • Maximum number (percentage) of non-authenticated externals authorized.

12. IMMUNITY REQUIREMENTS • Objectives : • protect itself from infection by unauthorized undesirable programs (e.g., computer viruses, worms, and Trojan horses). Example : • Scanning • Prevention • Notification

13. IMMUNITY REQUIREMENTS • Guidelines : • Used to implement : • Commercial antivirus programs. • Firewalls. • Programming standards (e.g., for ensuring type safety and array bounds checking). • Measurements : • Minimum number(percentage) of malicious programs identified. • Minimum number(percentage) of malicious programs prevented from causing infection. • Minimum number(percentage) of malicious programs cured (removed from infected machine).

14. INTEGRITY REQUIREMENTS • Objective: • ensure that its data and communications are not intentionally corrupted via unauthorized creation, modification, or deletion • Example: • protect the data during transmitting or receiving data (attached files). • Guidelines: • Integrity requirements should not be specified in terms of the types of security architecture mechanisms that are typically used to implement them: - Cryptography - The use of hash codes • Measurement: • Maximum number of data files/records corrupted per unit time. • Maximum number of messages corrupted. • Maximum number of programs corrupted per unit time.

15. INTRUSION DETECTION REQUIREMENTS Objective: detect and record attempted access or modification by unauthorized individuals. & also notify security personal to handle unauthorized access Example: detect and record all attempted accesses or repeated that fail required identification, authentication, and authorization. So the application shall notify the data center security office. Guidelines: It depend on identification, authentication, and authorization requirements. Use to implements: Alarms, Error reporting, IDS (Intrusion Detection System) and IPS (Intrusion Prevention System) Measurement: Minimum percentage of successful intrusions detected. Minimum percentage of unsuccessful intrusions detected

16. NONREPUDIATION REQUIREMENTS Objectives : • Ensure that adequate tamper-proof records are kept to prevent parties to interactions from denying that they have taken place. Example : • Stores temper-proof records of : • contents of the invoice • The date and time that the order or invoice was sent • The date and time that the order or invoice was received • Identity of customer

17. NONREPUDIATION REQUIREMENTS Guidelines : • To ensure that adequate tamperproof records are kept. • Used to Implement : • Digital signatures (to identify the parties) • Timestamps (to capture dates and times) • Encryption and decryption (to protect the information) • Hash functions (to ensure that the information has not been changed) Measurements : • Maximum percentage of transactions repudiated.

18. PRIVACY REQUIREMENTS Objectives : • keep sensitive data and communications private from unauthorized individuals and programs. • Provide access on a “need to know” basis. Examples : • Anonymity • Communications privacy • Data storage privacy

19. PRIVACY REQUIREMENTS Guidelines : • legal constraints such as laws that require certain data to be kept private. • Used to implement : • Public or private key encryption and decryption. • Commercial-off-the-shelf (COTS) cryptography packages. Measurements : • Anonymity: • As a function of threat, Maximum number (percentage) of confidential identities compromised per unit time • Confidentiality: • As a function of threat, Maximum number (percentage) of confidential data compromised per unit time

20. SECURITY AUDITING REQUIREMENTS Objectives : • enable security personnel to audit the status and use of its security mechanisms. Examples : • Security Audit Control • Security Audit Log Contents • Security Audit Reporting • Security Audit Log Protection

21. SECURITY AUDITING REQUIREMENTS Guidelines : • Care should be taken to avoid unnecessary duplication between security-auditing and intrusion detection requirements. • Used to Implement : • Audit Trails • Event logs Measurements • Minimum percentage of authorized users able to control security auditing. • Minimum percentage of security auditing commands correctly performed when requested by authorized users. • Minimum percentage of security events correctly logged.

22. SURVIVABILITY REQUIREMENTS Objectives : • Ensure that failure under attack is graceful, resulting in a degraded mode of operation that still provides essential services. Examples : • even if a data center is destroyed, The application shall continue to function (possibly in degraded mode) • Guidelines : • Critical for military applications • Deal with safeguarding against damage or loss due to intentional malicious threats • used to implement them: • Hardware redundancy. • Data center redundancy. • Failover software

23. SYSTEM MAINTENANCE SECURITY REQUIREMENTS Objectives : • prevent authorized modifications from accidentally defeating its security mechanisms. • to maintain the levels of security specified in the security requirements during the usage phase Examples : The application shall not violate its security requirements as a result of the upgrading or replacement of a data, hardware, or software component. Guidelines : • System maintenance security requirements may conflict with operational availability requirements • Used to implement : • Maintenance and enhancement procedures. • Associated training. • Security regression testing.

24. PHYSICAL PROTECTION REQUIREMENTS • Physical Protection means the physical measures designed to safeguard personnel, property, and information • Academic view definition • Technical view definition Objectives : • To protect and secure firms, companies, labs, individuals and structures. The level of protection depends on the type, location and nature of work and material.

25. PHYSICAL PROTECTION REQUIREMENTS Guidelines : • We must separate between physical protection and regular surveillance and security procedures, physical protection goes beyond that, it passes roles, instructions and ideas about how to create a safe environment to all. • Physical protection is not something you see but it’s something you live with.

26. Conclusion This research paper has addressed the need to systematically analyze and specify real security requirements as part of the quality requirements for a project.