1. Security in Software Engineering PRESENTED BY ROHIT MUKHERJEE AND RAMAKRISHNA VEERAVALLI

2. Goal  Minimize the number of security vulnerabilities design, implementation and documentation  Identify and remove vulnerabilities in the development lifecycle as early as possible!!!

3. Motivation  This application development process in its essence fails to address security issues.  very small number of companies invest in application security strategy, design, and code review services.

4. Overview  How much security ?  Security in SDLC  Privacy and Protection  Security Measurement Analysis  Reusing quality requirements

5. What is Software Security ?  Protect software against malicious attack and other hacker risks  Function correctly under such potential risks.  Provide integrity, authentication and availability.

6. Continued.. “100 Times More Expensive to Fix Security Bug at Production Than Design” – IBM Systems Sciences Institute Example :  SQL injections can be used to bypass login credentials.  Sometimes SQL injections fetch important information from a database or delete all important data from a database.

7. Threats and Vulnerability What are threats and vulnerability ?  Threats refers to anything that cause serious harm to a computer system.  A threat is something that may or may not happen, but has the potential to cause serious damage.  Vulnerability refers to a flaw in a system that can leave it open to attack.  A vulnerability is anything that leaves information security exposed to a threat.

8. How much security ?  Total security is unachievable.  More security means higher cost and less convenience and functionality.  Security should not irritate users Example: forcing a password change frequently. Effect : users stop using it. Choose security level according to your needs.

9. Security in SDLC Introduce security at every stage of software development.  Requirement analysis  Design  Implementation  Testing  Deployment.

10. Continued..  All security issues must be addressed  Risk analysis - Identifying the threats  Design - Use case diagrams for security  Implementation – follow coding standards  Code reviews  Through testing –software is secured or not

11. SOFTWARE PRIVACY AND PROTECTION  Software privacy is one of the challenges in software engineering  Security in software system has a significant financial impact  Security goals of a software system need to be satisfied by users who use the system, equipment around the software

12. Security Engineering Techniques  Encryption  Utilization of tamper resistant hardware  Mobile code  Watermarking

13. Continued  Each software product has license file.  License file has product key in order to authenticate the product.  Software product checks for the product key and system properties before starting functional operations.  Self-destruct approaches can be used when pirated copies of software product found.  Software will be stored in encrypted form on any machine and decrypted prior to execution using an independently stored key.

14. software security measurement analysis(SSMA)  Software assurance means how much extent the software is free from vulnerabilities.  SSMA addresses two questions.  How much extent the software system is secured to perform operational needs.  Ascertain the degree, whether the software system achieved the intended level of security or not.  17 drivers were provided to measure security in SSMA.  Drivers will check whether objectives or not.

15. [4]

16. SECURITY QUALITY REQUIREMENTS ENGINEERING(SQUARE)  SQUARE involves the communication between requirement engineering team and stakeholders.  Requirement team carefully analyzes the requirements  Categorize and prioritize the requirements for management use.  Final stage is inspection.This stage verifies security requirements, whether they are consistent or not.  By applying SQUARE, vulnerabilities, potential attacks and threats can be removed  The life time of the product will be increased.

17. Activity-Based Quality Model(ABQM)  Activities describe actions that can be performed on or with the support of the system.  Allows the efficient reuse of quality requirements.  Efficiently support the reuse of requirements among differing volatile project environments  ABQM needs a notion of projects and its goals and parameters

18. [2]

19. Conclusion  Security must be addressed in every phase of SDLC.  Total security is unachievable.  By applying SQUARE, threats can be detected at the earlier phases.  Reuse of quality requirements by using ABQM.

20. References [1] Baca, Dejan., Carlsson, Bengt., Agile development with security engineering activities,Proceeding ICSSP '11 Proceedings of the 2011 International Conference on Software and Systems Process,New York, NY, USA, 05-21- 2011, Pages 149-158. [2] Luckey, Markus., Baumann, Andrea., Méndez, Daniel., Wagner,Stefan., Reusing security requirements using an extended quality model, Proceeding SESS '10 Proceedings of the 2010 ICSE Workshop on Software Engineering for Secure Systems, New York, NY, USA, 05-02-2010, Pages 1-7. [3] M Kiran Kumar, T., A Road Map to the Software Engineering Security, Proceeding ICCEE '09 Proceedings of the 2009 Second International Conference on Computer and Electrical Engineering - Volume 02, IEEE Computer Society Washington, DC, USA, 12-28-2009, pages 306-310. [4] Mead, Nancy R., Measuring the Software Security Requirements Engineering Process, Proceedings Computer Software and Applications Conference Workshops (COMPSACW), 2012 IEEE 36th Annual, Izmir, Turkey, 07-16-2012, Pages 583 – 588. [5] Radack, Shirley., The System Development life cycle, Communication Research Student Conference (CRSC) on software life cycle security 2009, Federal Information Processing Standards(FIPS) and Information Technology Laboratory (ITL) Bulletins, Italy, Rome,04-21-2009.pages 231-235. [6]Walden,James., E Frank,Charles., Secure software engineering teaching modules, Proceeding InfoSeCD ’06 proceedings of the 3rd annual conference on information security curriculum development, New York, USA, 09-22-2006, pages 19-23.