A Systems Perspective on Building Security Into Applications

1. A Systems Perspective on Building Security Into Applications Dr. William J. Hery Polytechnic University hery@isis.poly.edu

2. When Do You Build In Security? • In developing the application requirements • In the processes used for application design/development • In the application design and code • In application life cycle management

3. Understand and Prioritize the Requirements • Confidentiality • Integrity • Unauthorized changes, creation, deletion of information • Detecting loss of integrity • Preventing loss of integrity • Availability Understanding of the detailed “requirements” and their relative importance is at the heart of building a good system and making tradeoffs: you cannot build perfect security into a usable system Discussion topics • Where do the requirements come from? (risk analysis, policy, legal…) • How does this fit in with rapid prototyping, agile programming, extreme programming etc.?

4. Use a Design/Development Process That Builds in Security • Secure code has two aspects: • Implementing security specific functions ( crypto, access control, etc.) properly (doing the right things) • Having robust code that does not allow bugs anywhere to open up security holes (doing things right) • Issues for development of robust code are essentially the same as those used for developing reliable, fault tolerant, and safety critical code: minimize bugs that impact critical elements and provide fail safe protections for failures in both the application and the “hardened environment” • For robust code, look at processes used in flight control systems, nuclear reactor control software, and the POTS telephone system • When was the last time you picked up a land line phone and didn’t get a dial tone? • Controlling switched circuits is a multi-million line of code, highly distributed application on heterogeneous platforms. • These processes may be overkill for your environment, but there are lessons to be learned and used as a basis for a documented process appropriate for your environment

5. Use a Design/Development Process That Builds in Security II Typical elements of robust development processes • Up front systems engineering and requirements analysis • Regular, rigorous design and code reviews by people not on the development team • Design and coding standards, best practices, etc. that are enforced at the reviews (e. g., bounds checking on all inputs, fail safe conditions in critical code segments, domain specific standards) • Source code control including integrity checking • Rigorous, repeatable testing procedures • Metrics • … Discussion Topics • You may be able to write bug free code, but can everyone else on your development team? • Management support for a process that will take more time and cost more money without adding functionality is critical • How does this fit in with rapid prototyping, agile programming, extreme programming etc.?

6. Current Research in Secure Programming at Polytechnic • Use static analysis techniques to detect security problems on the application level • Detect problems in code • Detect problems in configuration of distributed components • Detect mismatches between code and configuration files • Track the flow of information through the program to identify potential information leaks • Developing a comprehensive tool for examining Enterprise Java code and configuration files from the standpoint of security • Prof. Gleb Naumovich , gleb@poly.edu

7. ADV: Application Security Course at Polytechnic • Emphasis on avoiding security bugs in • Code • Configuration of distributed components • Hands-on experience in • Configuration and deployment of distributed applications • Avoidance of exploits of bugs and usability features • Application of security mechanisms and cryptography in practice • A multi-phase group project • Start with a J2EE program with numerous security holes (provided by instructor) • Re-design and re-implement to remove security holes • Attempt to exploit bugs in other groups’ solutions • Focus on Enterprise Java, but techniques are applicable in other environments. • Prof. Gleb Naumovich, gleb@poly.edu