Live Event - Good Security Starts with Software Assurance

1. Welcome! The live event will begin at 2PM ET. Q&A sessions with the presenters will follow. Please have your speakers turned on. Do you hear the music? Tweet with us live @SWAMPTEAM & @TENandISE

2. Good Security Starts with Software Assurance Jan. 23, 2014

3. Agenda • Agenda: • 2:00pm EST – Welcome Remarks – Barton Miller • 2:10pm EST – SWAMP High Level Overview – Pat Beyer • 2:25pm EST – Executive Insight – Phil Agcaoili • 2:45pm EST – Q&A • 3:00pm EST – Program Conclusion • You may earn 1CPE for this event. If you would like us to submit on your behalf, please email your certification number to Deb Jones at • djones@ten-inc.com.

4. Welcome! Prof. Barton P. Miller, Chief Scientist

5. Nothing New Under the Sun In November 1988, Robert Morris Jr. released the first Internet worm that shutdown the entire Internet (literally): The enabling exploit was a buffer overflow caused by not checking the bounds on a C character buffer. In 1989, we introduced fuzz random testing and studied the robustness of system utilities on a wide variety of UNIX implementations (and could crash 25-40% of them): The #1 source of errors were uncheck bounds on strings. Still this year, in the CWE/SANS Top 25 Most Dangerous Software Errors (www.mitre.org/top25): #3 on the list is unchecked bounds on strings. 1*&^28a@$!AfdF348f%$#e3212qWa00.?&$3a2d

6. And Plenty of New Stuff, Too • Since then, we also have to worry about: Injections (SQL, command line, code) Numeric attacks Exception attacks Race attacks (TOCTOU) File path name manipulations Privilege escalations Sandbox escapes VM escapes DNS spoofing Web attacks (cross site scripting, cross site forgeries, session hijacking, open redirect) • … just to mention a few.

7. Your First Line of Defense: Clean Code • We need to teach our programmers to write code with security in mind. … and … • We need to equip them with the tools to help them do so: Software assurance tools are our first line of defense: source code analysis, binary analysis, dynamic analysis, and domain specific (mobile, web) … and … • We need to make it easy to run these tools: The SWAMP will be a key asset.

8. Run the Tools Early, Run Them Often Build in security from day one, or the task becomes overwhelming for the programmer to fix them all: dthread.h: In constructor ‘ScopeLock::ScopeLock(Mutex&)’: dthread.h:132: warning: unused variable ‘result’ dthread.h: In constructor ‘ScopeLock::ScopeLock(CondVar&)’: dthread.h:140: warning: unused variable ‘result’ src/irpc.C: In member function ‘void int_iRPC::setState(int_iRPC::State)’: src/irpc.C:118: warning: unused variable ‘old_state’ src/irpc.C:119: warning: unused variable ‘new_state’ src/irpc.C: In member function ‘bool int_iRPC::saveRPCState()’: src/irpc.C:714: warning: unused variable ‘result’ src/irpc.C:723: warning: unused variable ‘result’ src/irpc.C:736: warning: unused variable ‘result’ src/irpc.C:1030: warning: unused variable ‘result’ src/irpc.C:1041: warning: unused variable ‘result’ src/irpc.C:1081: warning: unused variable ‘result’ dyninst/proccontrol/src/response.h:35, dyninst/proccontrol/src/int_process.h:39, dyninst/proccontrol/src/mailbox.C:33: dthread.h: In constructor ‘ScopeLock::ScopeLock(Mutex&)’: dthread.h:132: warning: unused variable ‘result’ dthread.h: In constructor ‘ScopeLock::ScopeLock(CondVar&)’: dthread.h:140: warning: unused variable ‘result’

9. Provide the Facilities Needed toRun Them Early and Often The SWAMP offers: • The automation to run tools easily: applying a tool to a new software package takes little effort. • The automation to run tools easily: get feedback on each code update or commit. • The resources to run many tools over each software package on each relevant platform. • The smarts to combine results in unified reports. • The ability to track progress and trends over time.

10. Help for Both the Novice and Expert The novice will be able to start using assurance tools with little effort or preparation. With management guidance that requires clean commits, the code stays in stable condition. The expert does familiar tasks, but with less effort and more precision. Running tools is easier, tracking results is easier, and understanding their performance over time is easier.

11. And Now, a Message from theFront Lines

12. Vision of the SWAMP Patrick D. Beyer PhD, PMP Project Manager Software Assurance Marketplace Morgridge Institute for Research

13. THE SWAMP • This five year, $23M project is led by the Morgridge Institute for Research, which also provides a state-of-the-art, secure hosting facility.

14. What is the SWAMP? The Software Assurance Marketplace is: • 5 year, $23 Million Grant • Funded by Department of Homeland Security, Science and Technology Directorate • Goal is to build a facility where open source software can be tested for vulnerabilities for FREE • Enable Software Researchers a place where they can do research in new testing tools

15. Team Profile • Building and Operating the SWAMP is a joint effort of four research institutions – Morgridge Institute for Research (lead), Indiana University, University of Illinois Urbana Champaign and University of Wisconsin – Madison

16. The Problem Increased Use of Open Source Software in product development • Why use open Source Software* • High reliability • Peer Reviewed • Low Cost • Speeds Development cycle • Concerns • Unverified Code • Unknown Source • Hidden Vulnerabilities * Open Source Initiative – opensource.org

17. Solution Test and Analyze Open Source Software • Many Analysis tools available (Not One Size Fits all) • May Require dedicated test environment (Sand Box) • Cost/Time prohibitive for small developers to maintain tools • Non-standard Results from Different tools

18. Continuous Integration vs.Continuous Assurance Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. Continuous Assurance (CoA) takes the software engineering practice of Continuous Integration to a new level. CoA incorporates SwA tools into the frequent process of building and testing the software throughout its life cycle.

19. Continuous Assurance Laboratory(COSALAB) Housed in the Wisconsin Institutes for Discovery • Intel Xeon Processors • 700 cores • 5 TB of RAM • 104 TB of HDD space • Capable of 12 teraFLOPS (12 trillion floating-point operations per second)

20. Initial Operating Capabilities Once Live, the SWAMP will give users access to: • 5 Assurance tools (2 Java, 3 C/C++) • 100 Packages (Code with Known Vulnerabilities to test tools) • Support for 8 Operating Systems (Linux, Windows)

21. Results Viewer The SWAMP will provide a simple result viewer: • Output parsedto individual weaknesses with location • A single software package can be assessed multiple times • Different Tools • Different Tool Versions • Different Operating Systems • Multiple results merged, filtered and sorted into a common viewer interface

22. Results Viewer • The SWAMP will provide a Commercial Viewing Tool: Code Dx (DHS SwA Grant Performer) Code Dx is a software assurance visual analytics tool that is being built by Secure Decisions to visualize and correlate weakness data from disparate code analysis tools, putting them into the proper context for effective triage and mitigation.

23. SWAMP Core Services • Manage Accounts, Projects and Access Control • Manage Software Packages and SwATools • Assess a Software Package • View Assessment Results and the Dashboard • Conduct Continuous Assurance SWAMP Standard Tools/Packages JOIN SWAMP Build Assessment Run RUN AN ASSESSMENT VIEW RESULTS

24. Future Capabilities

25. Software AssuranceExecutive Insight Phil Agcaoili Jan. 23, 2014

26. “An ounce of prevention beats a pound of cure.” ~Ben Franklin

27. Discussion Points • The Ubiquitous Presence of Software • The Appetite for Assured Software • Assured Software is Smartware • By the Numbers • Assured Software Benefits • The Path Forward

28. The Ubiquitous Presence of Software • It’s the driving force behind day-to-day life (literally) • Right now, you are reading this rendering enabled by millions of lines of code…software • Transportation: It runs your car’s Controller Area Network (CAN) bus and manages control surfaces and a whole bunch of other stuff on aircraft…software • Power: utilities, water, natural gas all delivered via...software • Banking and finance: ATM, POS systems...yup software • Manufacturing: Oh, that precision targeting maneuver performed by the gamma knife at the medical center…..uh-huh, software controlled • We put a lot of faith in unassured and incompetent software. Would you let a 7 year old drive you around on the highway? Pilot an aircraft or balance your checkbook?

29. The Appetite for Assured Software • The organizational appetite for assured software is driven by the net losses realized from compromised software • The consumer has been living with nearly 60 years of poorly developed and incompetent software. • Hundreds of millions of dollars are spent annually on post software compromise and incident recovery, lost opportunities and productivity (ask me). • Insecure software represents a pervasive kinetic threat to critical infrastructure and our way of life…..make no mistake about it. • The prudent approach is to take a proactive one. That is, software assurance measures must be a top integration priority in the enterprise cyber security risk management schema.

30. Assured Software is Smartware • Smartware is software which contains superior qualitative and qualitative attributes. It is: • Secure – Free of common vulnerabilities and exposures • Safe – Any single function does not conflict or impede upon other software functions resulting in severe and deleterious outcomes • Reliable – Code can perform repeatedly, as expected, over extended periods of time without degradation • Functional – Code is efficient and is designed to only perform a discrete (purposeful) function and no more • Extensible – Code is modular and has strong reuse characteristics (secure, safe, reliable and functional)

31. By the Numbers • Feel my pain. Lack of a good software assurance program is a painful experience • At one time – 127 applications were tested and; • 81 (64%) contained high vulnerabilities that facilitated exposure of sensitive data or system take over; • 45 applications (36%) exposed Personally Identifiable Information (PII) • At another time – 50 applications were tested and; • 41 applications (82%) hosted OWASP top 10 defects • 5 applications (10%) taken offline due to high risk • 19 (38%) contained high vulnerabilities that facilitated exposure of sensitive data or system take over • 12 applications (24%) exposed PII

32. Assured Software Benefits Programs such as the SWAMP provide excellent bottom line and programmatic benefits. Over time, application development gets faster and software quality increases significantly because developers learn to code securely (Thank you John Keane) Program managers can clearly demonstrate cost avoidance through defect identification and remediation during the development and test stages Software built under assurance standards processes streamline security approvals. Subsequent applications that adhere to the same standards can readily inherit accreditation and authorization

33. The Path Forward • The SWAMP is ripe for providing assurances that software is secure. The time to implement software assurance in the development lifecycle is now. • Patching is passé. Frankly, I’m tired of buying toys that are already broken when I take them out of the box • Given the austere budget environment, showing value through ROI and cost avoidance goes a very, very long way • The SWAMP provides mechanisms that can render the security posture of the enterprise “measurable better” • Community. This must be a community effort. No single tool, process, person or organization can solve this issue. While this challenge appears intractable, it is not. The whole is in fact greater than the sum of its parts and to that end, we must continue to take on the challenge as a community.

34. Things I challenge you to think out…. • Is software security important for you and your company? If not, why? • Where have you been successful promoting and implementing application security? • Where are you stuck? • What's holding you back? • Funding? Support? The need to deliver over security? • How do we fix this?

35. Any questions?

36. Thank you for attending! An on-demand version of today’s event with Q&A session will be offered soon for viewing by you and your colleagues. An announcement will be emailed when the on-demand event premiers. @SWAMPTEAM