Designing Flexibility in Software to Increase SecurityLarry Moore, CISSP CISAOctober 22, 2015

About

Code A

Code A

TimeThe only constant in business is change.

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

Outside InfluencesOperating system changesDeprecated APIsArchitecture changes (motherboard)New laws and/or regulatory requirementsPCI testing procedures change over timeOutside legitimate hacksThird party and customer demandsBusiness changes such as new opportunitiesCompetition

Security & FlexibilityChanges in security protocolsOUT: SSL; IN: TLSOUT: MD5; IN: SHASecurityNOW Podcasts499: InstantCryptorIncorrect security implementation, encryption without authentication530: Doing it WrongFour examples of companies making security mistakesPCI

Flexibility AdvantagesImproved scalabilityLower maintenance costsThe 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 lifecycleReduces impact to customersYour career!

Flexibility DisadvantagesMore easily abused especially by managementAdditional overheadAdditional sizeLower performanceGenerally decreasing because of increasing processor speedIntegrity may be impacted because of generalization of data structures

Timeline - 1977Factors in Software QualityGriffiss Air Force Base and General Electric, NYThis 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 functiontoward 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, ModifiabilityEffort required to modify an operational programA system that is not flexible costs more and takes longer to change.Focuses on:Identify a set of quality factorsMetrics throughout the development cycleCommunicate results to senior management (Air Force)

Factors in Software QualityFlexibility vs. Integrity: Flexibility requires very general and flexible data structures. This increases the data security problem.May be mitigated through XML

Specification ErrorDesign ErrorCoding ErrorTest ErrorCost to FixTimeImpact to fix after delivery

Business ResistanceBe first on the marketFirst is not always best; others may learn at your expenseSell it now, fix it laterGenerally higher help desk costsLimited budgetsRegulatory requirements and customer feedbackFour types of business risk:Finance: Loss of customers or revenueReputation: Loss of trust or loss due to competition or public opinion (true or false) Compliance: Fines or penalties; loss of businessCertainty of non-compliance vs. possibility of a breachLiability: Civil litigation

Architectural ChangesArchitectureReleaseMicroprosessor Bits808819798808680286197819841680386198532Current2001 -200364

Architectural ChangesIf unsigned int x in C equals.x = 0xFFFF ORx = (unsigned int) -10xFFFF-116 Bit0xFFFF0xFFFF32 Bit0x0000FFFF0xFFFFFFFF64 Bit0X000000000000FFFF0xFFFFFFFFFFFFFFFF

Example

Integrity

OS/2 Postscript Driver

1.0 to < 2.1

Caught betweenManagementOS/2 VendorsMe

OS/2 Postscript Driver

2.1 & later

StandardsDefine the framework and use itEncapsulationPossible even with non-object oriented codeMinimize the use of global variablesTry to predict changesPolymorphismCommon interfacesSet short-term definable goals and include metricsInvolve various business units to ensure proper scopeEnforce scopeInclude dependencies in your requirements and plan for the possibility of requirements failures

StandardsCreationZero all buffer contentsNullify all pointersSet all variables to a Non-Defined or Not-In-Use stateConsider hashes or algorithms for immutable values; check periodicallyUseProper read and write interfacesVerify all data before modifications outside of your codeRestrict access of values via interfacesUse proper error return valuesDeletionMost of the same as CreationRemember: Data must be under your control only between Creation and Deletion

Why Standards?Designing standards into the earliest versions forces customers to adhere appropriatelyOnce customers use your product theyre, in a sense, locked onto your standardsCustomers will sacrifice security and may blame you if there are any vulnerabilitiesChanging products can be expensive and time-consuming. That will likely create dissatisfaction with your productCustomers will expect change but only to a certain point

Static Code AnalysisPROSGreat for low-cost identification of clear errorsVariety 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 expertsCONSStatic focuses on immediate issues yet misses many strategic goalsNot very useful to identify vulnerabilities from a 30,000 foot levelMany people have missed vulnerabilitiesHeartbleed and Shellshock

ModularityA technique that emphasizes separating program functionality into independent, interchangeable modulesData trust only exists directly between trusted modulesTrust is broken any time an outside process touches data for a trusted moduleGlobal data is kept to an absolute minimumVerify, verify, verify!Document, document, document!Enforce standards rules

ModularityObject-oriented codeMethods 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.

ModularityProcess(Private)Conversion

Core process is shielded from the rest of the programConversion or sanitization process ensures that code is protectedModifications are primarily processed by the converter then by the internal processThe separation process enables easier development

ModularityFunction A (old)Function B (new)

Process(Private)

Modularity ExampleExample: Alexander DAlessandroNote the apostropheOHara (Ohara), DAbo, Smith-Jones, etc.

Example#define UNDEFINED_AGE ((unsigned int) -1)#defined MIN_AGE 0 /* newborn */#defined MAX_AGE 100unsigned int current_age;Creation and Deletioncurrent_age = UNDEFINED_AGE;

Exampleif (current_age == UNDEFINED_AGE){}else if (current_age >= MIN_AGE && current_age MAX_AGE){

}else{}

Agile MethodologyAgile is a more flexible Implements more object-oriented software development through smaller, more incremental workEncourages simplicityEnables faster changesInvolves cross-platform teams across the enterpriseBaseline for:ScrumExtreme programming (XP)Rational Unified Process (RUP)The Waterfall model is still used today but is not very effective in modular design.

What About Security?ModularityEnforces standardsDevelopers will bypass standards if you permit itDevelopers will hack public data (not melovantly) if permittedYour 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 customerMigrating from one security protocol to another

Career RecommendationsNever disclose sensitive or private informationRead and understand all NDA agreements. Obey them!Err on the side of cautionMetrics are criticalEase of modifying codeMinimum number of defects per line of codeForward thinking Security is the focal point of my development!

Questions?Larry Moorelarry.moore.cissp@gmail.comhttps://www.linkedin.com/in/lawrencemoore

RecommendationsThe Power of Ten - Rules for Developing Safety Critical CodeGerard J. Holzmann, NASA JPL Laboratory for Reliable Software; 2006Formalizing Space Shuttle Software RequirementsJudith Crow, Computer Science Laboratory, 1996Two 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 TestingNIST, May 2002

ReferencesAdrian, David; Bhargavan, Karthikeyan, et. al; Imperfect Forward Secrecy: How Diffie-Hellman Fails in PracticeAgile Modeling: http://www.agilemodeling.com/essays/agileModelingRUP.htmLieblein, E., Computer Software: Problem and Possible Solutions, CENTACS USAECOM Memorandum, 7 November 1972Factors in Software Quality: http://www.dtic.mil/dtic/tr/fulltext/u2/a049055.pdf