Designing Flexibility in Software to Increase Security
- 1. Designing Flexibility in Software to Increase Security Larry Moore, CISSP CISA October 22, 2015
- 2. About Code A Code A’ Time The only constant in business is change.
- 3. What is Flexibility? Software design that promotes modularity and can be easily modified to adjust to internal and external changes such as customer demands, architecture modification, regulatory compliance modifications or other factors while maintaining a consistent proactive security posture. Best during the requirements analysis phase and followed through during design and implementation Quality = Security
- 4. Outside Influences • Operating system changes • Deprecated API’s • Architecture changes (motherboard) • New laws and/or regulatory requirements • PCI testing procedures change over time • Outside legitimate hacks • Third party and customer demands • Business changes such as new opportunities • Competition
- 5. Security & Flexibility • Changes in security protocols • OUT: SSL; IN: TLS • OUT: MD5; IN: SHA • SecurityNOW Podcasts • 499: InstantCryptor • Incorrect security implementation, encryption without authentication • 530: Doing it Wrong • Four examples of companies making security mistakes PCI
- 6. Flexibility Advantages • Improved scalability • Lower maintenance costs • The cost of fixing errors after a system is operational is up to 30 times greater than if the error was caught during system testing. • Lieblein, E. (see Reference at end) • Extends lifecycle • Reduces impact to customers • Your career!
- 7. Flexibility Disadvantages • More easily abused especially by management • Additional overhead • Additional size • Lower performance • Generally decreasing because of increasing processor speed • Integrity may be impacted because of generalization of data structures
- 8. Timeline - 1977 • Factors in Software Quality • Griffiss Air Force Base and General Electric, NY • “This report has stressed the methodology of deriving and validating the normalization functions to encourage the application of these techniques to other software development. Use on future developments will add to the data base for the establishment of generalized normalization function…toward a higher quality product.” • Flexibility was included in the top list of 11 out of 55 software quality factors. It extends to Accessibility, Adaptability, Augmentability, Expandability, Extensibility, Modifiability • Effort required to modify an operational program • A system that is not flexible costs more and takes longer to change. • Focuses on: • Identify a set of quality factors • Metrics throughout the development cycle • Communicate results to senior management (Air Force)
- 9. Factors in Software Quality • Flexibility vs. Integrity: Flexibility requires very general and flexible data structures. This increases the data security problem. • May be mitigated through XML Cost to Fix Time Impact to fix after delivery
- 10. Business Resistance • Be first on the market • First is not always best; others may learn at your expense • Sell it now, fix it later • Generally higher help desk costs • Limited budgets • Regulatory requirements and customer feedback • Four types of business risk: • Finance: Loss of customers or revenue • Reputation: Loss of trust or loss due to competition or public opinion (true or false) • Compliance: Fines or penalties; loss of business • Certainty of non-compliance vs. possibility of a breach • Liability: Civil litigation
- 11. Architectural Changes Architecture Release Microprosessor Bits 8088 1979 8 8086 80286 1978 1984 16 80386 1985 32 Current 2001 - 2003 64
- 12. Architectural Changes If unsigned int x in C equals…. x = 0xFFFF —OR— x = (unsigned int) -1 0xFFFF -1 16 Bit 0xFFFF 0xFFFF 32 Bit 0x0000FFFF 0xFFFFFFFF 64 Bit 0X000000000000FFFF 0xFFFFFFFFFFFFFFFF
- 14. OS/2 Postscript Driver 1.0 to < 2.1
- 15. Caught between… Management OS/2 VendorsMe
- 16. OS/2 Postscript Driver 2.1 & later
- 17. Standards • Define the framework and use it • Encapsulation • Possible even with non-object oriented code • Minimize the use of global variables • Try to predict changes • Polymorphism • Common interfaces • Set short-term definable goals and include metrics • Involve various business units to ensure proper scope • Enforce scope • Include dependencies in your requirements and plan for the possibility of requirements failures
- 18. Standards • Creation • Zero all buffer contents • Nullify all pointers • Set all variables to a Non-Defined or Not-In-Use state • Consider hashes or algorithms for immutable values; check periodically • Use • Proper read and write interfaces • Verify all data before modifications outside of your code • Restrict access of values via interfaces • Use proper error return values • Deletion • Most of the same as Creation • Remember: Data must be under your control only between Creation and Deletion
- 19. Why Standards? • Designing standards into the earliest versions forces customers to adhere appropriately • Once customers use your product they’re, in a sense, “locked” onto your standards • Customers will sacrifice security and may blame you if there are any vulnerabilities • Changing products can be expensive and time-consuming. That will likely create dissatisfaction with your product • Customers will expect change but only to a certain point
- 20. Static Code Analysis • PROS • Great for low-cost identification of clear errors • Variety of software engineers approach threats from different perspectives They also contain a variety of experiences. • Excellent way of improving development skills by learning from other experts • CONS • “Static” focuses on immediate issues yet misses many strategic goals • Not very useful to identify vulnerabilities “from a 30,000 foot level” • Many people have missed vulnerabilities • Heartbleed and Shellshock
- 21. Modularity • A technique that emphasizes separating program functionality into independent, interchangeable modules • Data trust only exists directly between trusted modules • Trust is broken any time an outside process “touches” data for a trusted module • Global data is kept to an absolute minimum • Verify, verify, verify! • Document, document, document! • Enforce standards rules
- 22. Modularity • Object-oriented code • Methods are declared private by default an only lowered to a less secure level when necessary. • Any data that is declared public or protected is to be considered untrusted. Declare data as either only when absolutely necessary. • Public methods are more trustworthy to “shield” internal data thus permitting internal changes when necessary. • Deprecated public access points may be retained if needed for backward compatibility.
- 23. Modularity Process (Private) Conversion • Core process is shielded from the rest of the program • Conversion or sanitization process ensures that code is protected • Modifications are primarily processed by the converter then by the internal process • The “separation process” enables easier development
- 24. Modularity Function A (old) Function B (new) Process (Private)
- 25. Modularity Example • Example: Alexander D’Alessandro • Note the apostrophe • O’Hara (Ohara), D’Abo, Smith-Jones, etc.
- 26. Example #define UNDEFINED_AGE ((unsigned int) -1) #defined MIN_AGE 0 /* newborn */ #defined MAX_AGE 100 unsigned int current_age; Creation and Deletion current_age = UNDEFINED_AGE;
- 27. Example if (current_age == UNDEFINED_AGE) { } else if (current_age >= MIN_AGE && current_age <= MAX_AGE) { } else { <error handling> } /* First iteration will never be true since ‘current_age’ is */ /* unsigned. */ /* UNDEFINED_AGE will be included in this context */ if (current_age < MIN_AGE && current_age > MAX_AGE) { <error handling> } else { }
- 28. Agile Methodology • Agile is a more flexible • Implements more object-oriented software development through smaller, more incremental work • Encourages simplicity • Enables faster changes • Involves cross-platform teams across the enterprise • Baseline for: • Scrum • Extreme programming (XP) • Rational Unified Process (RUP) • The Waterfall model is still used today but is not very effective in modular design.
- 29. What About Security? • Modularity… • Enforces standards • Developers will bypass standards if you permit it • Developers will “hack” public data (not melovantly) if permitted • Your manager will likely prefer to keep your customers happy over security. Accept it! • Permits you to make internal changes with little or no impact to the customer • Migrating from one security protocol to another
- 30. Career Recommendations • Never disclose sensitive or private information • Read and understand all NDA agreements. Obey them! • Err on the side of caution • Metrics are critical • Ease of modifying code • Minimum number of defects per line of code • “Forward thinking” • “Security is the focal point of my development!”
- 32. Recommendations • The Power of Ten - Rules for Developing Safety Critical Code • Gerard J. Holzmann, NASA JPL Laboratory for Reliable Software; 2006 • Formalizing Space Shuttle Software Requirements • Judith Crow, Computer Science Laboratory, 1996 • Two case studies in which requirements for new flight software subsystems on NASA's Space Shuttle were analyzed using mechanically supported formal methods. • The Economic Impacts of Inadequate Infrastructure for Software Testing • NIST, May 2002
- 33. References • Adrian, David; Bhargavan, Karthikeyan, et. al; Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice • Agile Modeling: http://www.agilemodeling.com/essays/agileModelingRUP .htm • Lieblein, E., “Computer Software: Problem and Possible Solutions”, CENTACS USAECOM Memorandum, 7 November 1972 • Factors in Software Quality: http://www.dtic.mil/dtic/tr/fulltext/u2/a049055.pdf