"Software security" is becoming a hot topic but true security must go beyond bounds checking and memory leaks. Outside forces such as customer demands, competition and regulatory requirements will eventually force changes in the software architecture so designing a flexible software architecture that reacts to those impacts while maintaining a security state is very critical.

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

13. Example
Integrity

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!”

31. Questions?
Larry Moore
larry.moore.cissp@gmail.com
https://www.linkedin.com/in/lawrencemoore

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