the case for software assurance

<Insert Picture Here>

The Case For Software AssuranceMary Ann DavidsonChief Security Officer

© 2008 Oracle Corporation 2

Agenda

• Current State of Insecurity• Raising the Bar: The Need for Software Assurance• Beyond Assurance: Creating Defensible Network

Elements• Solving the Right Problem: IT Supply Chain Risk• Conclusions


State of Information Security

• Another day, another data breach…• Increased costs of regulatory compliance • Increased intellectual property theft, including state-

sponsored intellectual property theft, often exploiting unknown vulnerabilities

• More network-addressible stuff … and more coming…which creates systemic risk• Medical devices, cars, home appliances, control systems…

• Routine discussions of “rules of engagement” for cyber war• Endless proposed/incipient regulation in multiple venues


Raising the Bar: The Case for Software Assurance (1)

• The story of the little Dutch boy• “There’s an app for that…”• “But it wasn’t designed for that!”• How to build in earthquake zones

Conclusion: What is used as infrastructure needs to be designed, built and delivered to be infrastructure.


Raising the Bar:The Case for Software Assurance (2)

• National defense has an increasingly heavy IT component• Technology is a force multiplier, or is it an “Achilles’

backbone?”

• Improving software assurance will:• Improve signal to noise in networks degraded from easy exploits• Make attackers work harder• Allow redeployment of $$$ spent on patching, maintenance, etc.

• Improved assurance (e.g., for defense) has knock-on benefits to many sectors of critical infrastructure


Assertions

• Lack of software assurance is a fundamental cultural problem manifested as a technical weakness• You can’t win a war if you don’t think you are in one• You don’t win on defense

• Customers are a much stronger catalyst for change than they think they are• Collective wave energy of the North Shore of O’ahu can light a

city• Collective buying power changes the market dynamic


What Needs to Change

• Education• How Customers Buy Software• Defensibility of Network Elements• Defensibility of Data


Education (1)

• Cultural shift must start in universities• The Epaminondasic Oath: “First, assume an

enemy…”• Could improve both code quality and malware issues• Goal: every developer thinks like a hacker

• Software vendors spend $$$ training CS grads in basic secure coding• And millions more remediating avoidable, preventable

defects resulting in large part from lack of basic security education


Education (2)

• The CS – and other related - curricula need to change to have security embedded within each class• Every course builds on a secure coding foundation• Red team/blue teaming part of each class

• Accreditation programs need to force this change• Governments should withhold research monies from

universities that refuse to modify their curricula


How Customers Buy Software (1)

• Require transparency in development practices, improving ability to do risk-based acquisition

• Require proof of assurance (e.g., Common Criteria evals, automated security testing done during development)

• Require vendors to do more in an automated way, lowering lifecycle cost-to-secure• Secure configuration by default• Minimal installations (don’t install what I didn’t license and don’t use)• Patch automation, etc.


How Customers Buy Software (2)

• “Procurement effect” can be magnified if large customer base acts as one

• Benefits of Big Buyer approach will accrue to multiple customers, raising the bar across many sectors

• Caution: general, standards-based uplifting works; multiple flavor variants won’t


Beyond Assurance: Defensibility of Network Elements

• The US Marine Corps is a lethal fighting force• But does not assume “no casualties and an unbreachable

perimeter”• And Marines understand what is strategic to defend (e.g.,

Henderson Field)

• “Every Marine a rifleman…”• Products must self defend, every one of them• “Armed guards” will not work any better than bastion

defenses, particularly as apps become collaborative• N devices should not require n defenders• Mentality shift in development to disallowing every other

possible future use instead of allowing all possible future uses


Beyond Assurance: Defensibility of Network Elements

• Lack of situational awareness is caused by lack of basic information• Who’s on my network?• What is on my network?• What is my “mission readiness” (performance, bandwidth, security

posture)• What is happening that I should be worried about?

• Causes• No standards for what data is collected • No standards for format (though some contenders)• SIEM vendors can’t correlate non-existing data• Value add is the BI component, not “translation services”


Beyond Assurance: Defensibility of DataData

• Search (and-destroy) engines? • What data is where on my networks?• Options include report/retrieve/erase/destroy?• The corollary to information lifecycle management/data

retention is what you should not have/use/keep• Can help with security/privacy housekeeping as well as data

retention policy

• More flexible access models?• Self sealing/time-to-live data• Narrow risk/attack vector through more contextual access

(time of day/pattern of use/who do I think you are/what device are you using)


Beyond Assurance:E-M Theory Applied to Networks

• Fighter pilots “win” based on agility (Boyd’s energy-maneuverability (E-M) theory)

• OODA (observe, orient, decide, act)• OODA was an air warfare concept that changed the face of

war (notably in Gulf War I)• And has been applied to other disciplines• Is there applicability to cyber-offense and defense?


Solving The Right Problem: IT Supply Chain Risk

• New boy band: Supply Chain Threats!• What is the real concern?• What is the real risk? • And to whom?• Everyone but God has a supply chain…

© 2008 Oracle Corporation

Setting the Supply Chain Stage

• Organizations often choose “commercial off the shelf” (COTS) software over custom code due to cost, feature richness, maintainability, 7x24 support, configurability…• …which is only possible with global development/ global

sourcing

• You can’t buy COTS and expect it to have been built in a secured facility by cleared <US, UK, Australian…> citizens

• All software has (undetectable) defects, some affect security and some are serious

• Vendors and customers have different supply chain concerns


Supply Chain Risk: Vendor Concerns

• Intellectual property risk• Theft

• Source code • Designs

• Code tainting• “Viral licenses”• Third party licenses

• Counterfeiting • Maintainability/recoverability

• Source code control systems…• Escrow


Supply Chain Risk: Customer Concerns

• “’Foreigners’ putting bad stuff in code”• Counterfeiting


What To Do?

• State concerns clearly! • Support/develop standards addressing targeted risks

(e.g., Open Group Trusted Technology Provider Framework, Common Criteria work on supply chain risk)

• Do not make “all risks of buying any product” into a supply chain risk or the real threats will not be addressed

• Do not conflate “origin” with “threat”


Summary

• Sid Sibi Pacem Para Bellum• Those who design and build critical information

systems need a warrior mindset reinforced by warrior training – and “war games”

• Systemic risk, by definition, cannot be mitigated• Systems need to be designed to be defensible –

instead of assuming a peaceful world• Customers are an important and absolutely necessary

catalyst for change


"A nation, as a society, forms a moral person, and every member of it is personally responsible

for his society.“

-Thomas Jefferson (in letter to George Hammond, 1792)


Q&A

the case for software assurance

Documents