The Case For Software Assurance

1. The Case For Software Assurance Mary Ann Davidson Chief Security Officer

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 2

3. 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 3

4. 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. 4

5. 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 5

6. 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 6

7. What Needs to Change • Education • How Customers Buy Software • Defensibility of Network Elements • Defensibility of Data 7

8. 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 8

9. 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 9

10. 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. 10

11. 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 11

12. 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 12

13. 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” 13

14. Beyond Assurance: Defensibility of Data • 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) 14

15. 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? 15

16. 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… 16

17. 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

18. 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

19. Supply Chain Risk: Customer Concerns • “’Foreigners’ putting bad stuff in code” • Counterfeiting

20. 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” 20

21. 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 21

22. "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) 22

23. Q & A 23

24. 24