Information Security Antipatterns in Software Requriements Engineering

1. Information Security Antipatterns in Software Requriements Engineering Miroslav Kis Presented by Liping Cai

2. Overview • Introduction • Case Study: Perimeter security model • Case Study: Security Design without assessment of the business value of the data • Conclusion

3. Introduction • Software Requirement Engineering • antipattern • 2 main problems we face • To secure an application without spending excessive time and effort • Design the application failing to understand the real value of data we need to protect

4. Perimeter Security: the Maginot line of enterprise application • Problem • Need to secure a typical n-tier enterprise application. • Background • User access the mainframe using terminals. • A separate wire is used to connect each terminal to the mainframe • Physical access to the terminals is limited to a small number of users. • Use password and firewalls were adequate. • Context • Users access the mainframe using intelligent terminals • All of the terminals are connected to the mainframe over a LAN • Most of company’s employees have access to the LAN through their computers • Attackers have been increased.

5. Perimeter Security: the Maginot line of enterprise application

6. Perimeter Security(Continue) • 2 main forces that influence the quality of the security solution: • Time to market • Difficulty with applying general system’s security theory in software development. • Faulty beliefs • Security is a plug-in feature added to the application once development is completed. • Antipattern solution • Apply perimeter security model to the modern enterprise application architecture.

7. Perimeter Security(Continue) • Consequence • Any communication between users and the mainframe in the intranet environment can be easily observed and altered by an attacker • Firewalls provide only partial control to the resources they are protecting. • Symptoms • Security requirements specification is postponed until the late phases of application development, and sometimes avoided altogether • Why is that solution not acceptable when it was fine before?

8. Perimeter Security(Continue) • Refactored Solution • Proper security requirement analysis should be performed in every case • Security analysis and design should go hand in hand with the analysis, design and deployment of the application • Integrate general system theory into the existing software development methodologies • Both software developers and security assessors need to have knowledge of software architectures, development methodologies and information security methodologies

9. Security design without assessment of the business value of the data • Problem – security of enterprise software application • Background • Determine the key elements of security requirement analysis • Data sensitivity analysis • Threat analysis • Context • Requirements gathering phase of the software development process.

10. Security design without assessment of the business value of the data(2) • Forces – same as the perimeter security antipattern • Faulty Beliefs • Technology is the solution • Business customers and users do not know what they need related to information security. • Antipattern solution • Business analysis of information security requirements is skipped. • A uniform protection of all of the resources in the application is implemented. • Usage of a strong encryption algorithm without real understanding why.

11. Security design without assessment of the business value of the data(3) • Consequences • Inadequate protection of the resources we have to protect • Symptoms • We will encrypt everything • Customer does not know what he needs • We will use the latest version of the security product xyz

12. Security design without assessment of the business value of the data(4) • Refactored solution • High-level version of data sensitivity analysis to identify data groups; • Detailed analysis • Threat analysis • Design the solution

13. Security design without assessment of the business value of the data(5) • Payroll Example • High-level data sensitivity analysis • Integrity: Employee name, phone num, address department and position • Confidentiality and Integrity: salary and SSN • Detailed analysis • Employee name, phone num, address – no unauthorized changes are made • department and position -- are not secret but whole organizational structure is kept secret • Salary is confidential • SSN should be strictly controlled • Availability of the whole system is critical the day before pay day.

14. Security design without assessment of the business value of the data(5) • Threat analysis for a small company • It is highly unlikely that somebody would try to alter telephone number, address, department and employee position files for a small company. • The organizational structure of a small startup is usually quite simple, and can be easily guessed without using the payroll application. • Some current employees and prospective candidates might be interested to know salaries. • Misuse of someone’s Social Security Number is a criminal act. In most cases, only criminals outside the company would be interested to obtain them. • Even an unfair competitor would not try to make the payroll system of the startup company unavailable. No significant harm could be made, nor any gain for the competition.

15. Security design without assessment of the business value of the data(5) • Threat Analysis for big company • Delaying pay checks for a day by altering employees’ personal information can cause a huge problem that can become publicly known. • The organizational structure of a large corporation might reflect their intention to develop a new product. The size of their R&D department may help their competition to understand it. • Both the employees and competitors could be interested to know salaries for several reasons. • As in the case of the small company, criminals outside of the corporation would be interested to obtain Social Security Numbers.

16. Conclusion • Application security is a difficult problem to solve. • The first antipattern shows that security cannot be treated as a feature to be added once the application development is completed. • the lack of data sensitivity and threat analyses leads to inadequate protection