1 / 32

Software Assurance MarketPlace SWAMP

Software Assurance MarketPlace SWAMP. Von Welch January 28 th , 2014 OWASP Bloomington. About Me. Deputy Director, IU Center for Applied Cybersecurity Research Principle Investigator on applied and basic research NSF, DOE, DHS projects.

vilmos
Télécharger la présentation

Software Assurance MarketPlace SWAMP

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Assurance MarketPlaceSWAMP Von Welch January 28th, 2014 OWASP Bloomington

  2. About Me • Deputy Director, IU Center for Applied Cybersecurity Research • Principle Investigator on applied and basic research NSF, DOE, DHS projects. • SWAMP IU Principle Investigator andChief Security Officer vwelch@iu.edu @VonWelch

  3. Outline • What is the SWAMP • The driving vision • Managed, secure sharing • How to get started?

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

  5. A Multi-Institute Team Effort Building and operating the SWAMP is a DHS S&T funded joint effort of four research institutions – Morgridge Institute for Research (lead), Indiana University, University of Illinois Urbana Champaign and University of Wisconsin – Madison

  6. Driven by a Comprehensive Vision • Our target customers are all the members of the Software Assurance (SwA) eco-system – tool developers, software developers, facility managers, researchers and educators. • The community needs a continuous assurance facility that will enable significant improvement in the quality of SwA tools and will lead to a broader adoption of SwA tools and SwA methodologies. • While protecting your privacy and the confidentiality of your data, the SWAMP will : • Identify new (possible) defects in your software every time you commit a change • Identify new (possible) defects in a software/library/module you are using every time a new version is released • Profile the ability of your SwA tool to identify (possible) software defects every time you commit a change • Exposeyour tools and software to the SwA community http://continuousassurance.org/wp-content/uploads/2013/10/SWAMP-VISION-10.28.13.pdf

  7. Based on a Open andEvolving Framework To meet the diverse and ever-changing needs and expectations of the different groups that compose the software assurance eco-system, a framework that offers the following key elements is required: • An environment where new tools can be added easily and efficiently • An environment where new software packages can be added easily • Support for tools that integrate and interpret the output of software assurance tools • An open framework with access to software products and results at all levels • A foundation for understanding the process of software assessment continuousassurance.org/wp-content/uploads/2013/11/White-Paper-Evolving-Framework.pdf

  8. A Powerful and Flexible Facility • A repository of software assurance (SwA) technologies • Assessment tools • Viewing tools • Integration and coupling tools • Risk assessment tools • A repository of software packages • Common open source packages • Reference test suites • A Continuous Assurance engine • A wide range of platforms • Automation of assessment workflows to support continuous invocation

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

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

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

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

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

  14. Outline • What is the SWAMP • The driving vision • Managed, secure sharing • How to get started?

  15. 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, Prof. Barton Miller, SWAMP Chief Scientist, 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.

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

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

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

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

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

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

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

  23. Continuous Assurance at Work • We have been working with Sonatype to automatically (end-to-end) generate a FindBug assessment for each of the more than 60K Java packages (more than 500K versions) in their “central” (publically available) repository. In a trial run we processed 11K packages.

  24. Outline • What is the SWAMP • The driving vision • Managed, secure sharing • How to get started?

  25. Managed Sharing for Stronger Assurance • Maximizing the impact of sharing requires tight protection of privacy. • Each user must maintain full control over the access to artifacts and information he/she owns. • Strong trust between the users and the SWAMP is key to the delivery of our vision.

  26. SWAMP Security • The SWAMP is a unique asset and its cybersecurity is critical. • We use a risk-based approach to create, and maintain, a tailored cybersecurity program for its protection.(Based on the NIST Risk Management Framework.)

  27. SWAMP Security • Best practices for network and host protection, and intrusion detection plus active defenses. • Pen-tested. • Software assurance program internally. • Strict separation of duties.

  28. Outline • What is the SWAMP • The driving vision • Managed, secure sharing • How to get started?

  29. Initial Operating Capacity • Open for users. • Scheduled for Feb 3rd. • Watch http://continuousassurance.org/ for details.

  30. Future Capabilities

  31. Get Involved! • Sign up for a “test drive” of the SWAMP in the privacy of your personal project while leveraging publically available tools and software • Talk to us about your software assessment needs, challenges and aspirations • Tell us about your software assurance tools and methodologies • Join us in our community building activities

  32. Contact Information Pat BeyerProject Managerpbeyer@ContinuousAssurance.org(608) 316-4664 Miron LivnyDirector and CTOmiron@ContinuousAssurance.org(608) 316-4336 @SwampTeam

More Related