Download to read offline
Uploaded byRogue Wave Software
Shifting the conversation from active interception to proactive neutralization
Rod Cope, CTO of Rogue Wave Software, emphasizes the necessity of proactive security measures in software development, particularly in managing open source components. He highlights that many organizations lack meaningful security controls and awareness, leading to vulnerabilities and delays in remediation. To combat these issues, he advocates for better tooling, education, and a shift from passive security responses to active prevention strategies.
More Related Content
Similar to Shifting the conversation from active interception to proactive neutralization
More from Rogue Wave Software
Shifting the conversation from active interception to proactive neutralization
- 1. Shifting the conversation fromactive interception to proactive neutralization Rod Cope, CTO
- 2. Presenters © 2015 RogueWave Software, Inc. All Rights Reserved. Rod Cope, CTO Rogue Wave Software 2
- 3. “With all software,there will be more security holes, you need to plan for it, have tooling, prepare for some notification process so you can quickly learn when there is an issue, whether it’s open source or from somewhere else, that you know there’s an issue, and then have a mitigation plan in place so you know what is affected.” -Rod Cope, CTO
- 4. Why the shift? 4©2015 Rogue Wave Software, Inc. All Rights Reserved. 150X as much as fixing the bug during the requirements or design phase. 76% of organizations using open source don’t have meaningful controls over what components go into their applications 55% of organizations don’t have security awareness program in place 78% of development teams use time consuming manual testing processes to ensure code security 72% of developers believe they are responsible for security and safety testing of their code 70% of development organizations don’t have clear policies, procedures, and tools for using open source code
- 5. What are therisks? Risks include OSS security issues Unknown OSS Outside reprogramming of systems Code vulnerabilities 5© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 6. Unknown OSS &security issues © 2015 Rogue Wave Software, Inc. All Rights Reserved 6
- 7. Outside reprogramming ofsystems 7© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 8. Code vulnerabilities 8© 2015Rogue Wave Software, Inc. All Rights Reserved.
- 9. © 2015 RogueWave Software, Inc. All Rights Reserved. Common attacks Organizations have failed to prevent attacks Lack of time Lack of focus Lack of tools/proper tools Survey: 1700 developers, 80% of them incorrectly answered key questions surrounding the protection of sensitive data SQL injection Unvalidated input Cross-site scripting Most breaches result from input trust issues Heartbleed: buffer overrun BMW patch: HTTP vs. HTTPS 9
- 10. Software suppliers can introducerisks (security, functional, compliance) before they reach you 10 Root causes of vulnerabilities Supply chain Software suppliers can introduce risks (security, functional, compliance) before they reach you Minimal testing Different platforms, processes, tools, standards, etc. require more effort to assess, test, and standardize Lack of prioritization Over 90% of companies use OSS components in commercial software1 46 million vulnerable open source components are downloaded each year Lack of developer education 1. Gartner © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 11. Multi-source software Open source Your product Legacy COTSContractors ISV Integrate Test cost to fix defects $$$$ $ 11© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 12. Traditional development: Securityas a service © 2015 Rogue Wave Software, Inc. All Rights Reserved. 12 Adaptive Separation of duties for testing and auditing Separate testing tools, results fed to development Traditional Secure Development Lifecycle Activities Design • Establish design Requirements • Analyze attack surface • Threat modeling Build • Use approved tools • Deprecate unsafe functions Test • Static analysis • Dynamic analysis • Fuzz testing • Attack surface review • Open source review Deploy • Incident response plan • Final security review • Release archive Development, compliance, and security are independent functions Req's • Establish security requirements • Create quality gates • Risk assessments
- 13. Consequences of securityas a service © 2015 Rogue Wave Software, Inc. All Rights Reserved. 13 Adaptive Cost of Remediation Source: Barry Boehm, “Equity Keynote Address” March 19, 2007 Cost of Remediation Increased remediation costs Delayed releases Security and development become adversarial 5x Design • Establish design requirements • Analyze attack surface • Threat modeling 10x Build • Use approved tools • Deprecate unsafe functions 20x 50x Test • Static analysis • Dynamic analysis • Fuzz testing • Attack surface review • Open source review 150x Deploy • Incident response plan • Final security review • Release archive 1x Req’s • Establish security requirements • Create quality gates • Risk assessments
- 14. Build-only analysis indev process Build Analysis / Test 14© 2015 Rogue Wave Software, Inc. All Rights Reserved. Cost of defects
- 15. Defect introduction 50% ofdefects introduced here Build Analysis / Test 15© 2015 Rogue Wave Software, Inc. All Rights Reserved. Cost of defects
- 16.
- 17. © 2015 RogueWave Software, Inc. All Rights Reserved. Shift your plan of attack Agile, continuous integration, continuous delivery Understanding processes Educating teams Implementing tools Enforcing compliance Measuring success Adopting new standards Systems integrators vs. systems builders Multiple development teams 17
- 18. Prevent software failuredue to defects Your team worries about Problems with array indexes Errors in error handlers Untrapped exceptions Memory leaks Unchecked stacks and buffers Misplaced pointers 18© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 19. Analysis and testing Checkcode faster 19 Source: https://uwaterloo.ca/counselling-services/curve-forgetting © 2015 Rogue Wave Software, Inc. All Rights Reserved. Issues identified at your desktop 1 Real-time feedback Correct code before check-in2 All areas impacted by a given defect are highlighted3 After system build, the impact of other developers code is also delivered to the desktop for corrective action 4
- 20. Traditionally used tofind simple, annoying bugs Modern, state-of-the-art SCA Sophisticated inter- procedural control and data-flow analysis Model-based simulation of runtime expectation Provides an automated view of all possible execution paths Find complex bugs and runtime errors: memory leaks concurrency violations buffer overflows Check compliance with internationally recognized standards: MISRA CWE OWASP ISO26262 20 Static code analysis © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 21. • Hundreds ofcheckers for C, C++, C# and Java • Support for numerous standards • Customizable: – Turn checkers on or off – Change the severity of identified defects – Add custom checkers Klocwork static analysis engine • MISRA, DISA, CWE, CERT, etc. • Dead code • Unreachable code Calculated values that are never used • Unused function parameters • … Coding Standards & Maintainability • Memory and resource leaks • Concurrency violations • Infinite loops • Dereferencing NULL pointers • Usage of uninitialized data • Resource management • Memory allocation errors • … Reliability • Buffer overflow • Un-validated user input • SQL injection • Path injection • File injection • Cross-site scripting • Information leakage • Vulnerable coding practices • … Security © 2015 Rogue Wave Software, Inc. All Rights Reserved. 20
- 22. Klocwork finds Heartbleed 22©2015 Rogue Wave Software, Inc. All Rights Reserved.
- 23. Use open sourcesoftware safely 23 “So the mystery is not that a few overworked volunteers missed this bug; the mystery is why it hasn’t happened more often.” -Steve Marquess, OpenSSL Software Foundation on the Heartbleed bug 80% of developers need not prove the security of OSS they’re using Only 7% of organizations have an OSS policy around security © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 24. Application code 3rd partycomponents If you’re using open source, security verification is up to you Do you know all the open source you are using? Test your code Look for flaws early Make security a priority © 2015 Rogue Wave Software, Inc. All Rights Reserved. 24
- 25. Use onlytrusted packages Notify and update security fixes Maintain with OSS support Automated, repeatable way to locate OSS packages (and packages within packages!) and licensing obligations Look for scanning tools that are SaaS and protect your IP by not requiring source code upload Know your inventory with OSS scanning Reducing open source risk 25 Get notified of latest patches, risks, and bugs Establish an OSS policy to minimize risk © 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 26. Open source management:OpenLogic Commercial-grade technical support for hundreds of open source packages Web-based platform for open source governance Open source scanning solutions Library of certified open source software with proactive security notifications 26© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 27. Security vulnerability example 27©2015 Rogue Wave Software, Inc. All Rights Reserved.
- 28. Scan results example 28©2015 Rogue Wave Software, Inc. All Rights Reserved.
- 29. Conclusions Tooling Notification processes OSS securitynotifications, latest patches Mitigation plan Shift from security as a service to security at the developer, correcting vulnerabilities as early as possible Code analysis and OSS scanning 29© 2015 Rogue Wave Software, Inc. All Rights Reserved.
- 30. See us inaction: www.roguewave.com Rod Cope| rod.cope@roguewave.com
Editor's Notes
- #6 There are several risks involved in securing embedded systems, some of those risks revolve around network intrusion, information theft, outside reprogramming of systems, and code vulnerabilities.
- #13 So when we examine security as it often happens during development, the functions are separate. In a traditional development environment, security, compliance, and development are separate, autonomous groups. The argument for this is the principal of Separation of Duties – in this case making sure that independence exists between development and security. Development builds a release, tests it for functionality, then passes it to security for testing. Security tools have traditionally been used only by security personnel, typically later in the development lifecycle. Tools include static analysis of source code, dynamic analysis of running applications, and scanning for vulnerable open source components. At each phase of the Secure Development Lifecycle, there are a number of best practices. Security requirements, threat modeling, and several other activities help organizations avoid problems later in the secure software development lifecycle.
- #14 The problem with this, in particular as it applies to an Agile environment, is that the testing happens late in the development process, independent of the development team. For example, Traditional static testing requires a compilable application, complete with all dependencies, usually only possible after significant development efforts.. Dynamic analysis, or pen testing, requires a finished application in a test environment, complete with data. By definition this will be very late in the development process. There have been many studies on the costs associated with delaying security testing, but the numbers remain fairly consistent. The later in the process a bug is identified, the more costly it is to remediate; up to 150X as much as fixing the bug during the requirements or design phase. It’s easy to understand why. Not only is it likely that more code refactoring will be required once an application is “fully baked”, but organizational costs come into play, including triage, prioritization, research, recoding, and retesting to ensure the fix didn’t introduce other problems. In short, costs are higher and releases are delayed. We recently had Jeffrey Hammond of Forrester present at an event, and he said “"It takes 18 months to deploy a new release of a project/product/app where a single line of code is changed.” Finally, we’ve seen this model result in conflicts between security and development teams. The development teams often feel that security has little involvement during the build process, to only parachute in late in the process, run code through their magic boxes, and produce a long list of bugs – with lots of false positives – just when the product is getting to its release date.
- #15 Everyone has seen this chart at some point I’m sure. It maps where software defects are found and the cost to fix them along the software development process. The later you find them the more it costs to fix them. With the Build-only approach to source code analysis, issues are being found before release but later in the cycle than most desirable.
- #17 Now we will discuss some solutions that we offer to ensure your developers are delivering secure, defect-free software in their embedded systems
- #19 Memory leak – a failure in a program to release discarded memory, which can build up over time causing impaired performance or failure. Untrapped exceptions – a failure at a higher level to catch errors generated at a lower level, causing unexpected behavior or crashes Unchecked stacks and buffers – unchecked areas where data is stored Misplaced pointers – does your pointer actually work/make sense? Problems with array indexes – Did your team put the array indexing in the appropriate place? Errors in error handlers – Error handling refers to the anticipation, detection, and resolution of programming, application, and communications errors. Sometimes there are errors within these areas. These types of bugs occur all the time and are sometimes easy to fix, sometimes not. The trick is detecting where these flaws are, especially in code that’s split over multiple files or even many developers
- #20 Graph: Continuous improvement fits well with the Agile methodology, which is built around brief, repeatable processes. Helping Agile teams avoid, rather than fix security issues should be a high priority. Rather than forcing developers to look up remediation advice on the web, or from internal coding standards, push that information directly to the IDE where it can be easily used. Studies show that people learn through repetition. The graph represents what is known as the “forgetting curve”. The black line in the graph shows memory retention from a single class. In terms of security training, this means that holding a secure coding training event can be helpful, but if the information is not reinforced quickly and consistently, over 90% of the knowledge from that class can vanish with the first week! If brief reminders are provided, as shown by the yellow line in the graph, knowledge retention improves dramatically, until it ultimately becomes part of a student’s long term memory. Pushing security testing and remediation guidance to the IDE also provides developers with near real-time feedback, improving their ability to recognize risky coding structures and self-correct.
- #22 We support hundreds of checkers which can be selected on an individual basis to fit the customer’s needs. We support numerous coding standards.
- #24 Julia to present this slide as we transition into open source software—OpenLogic
- #27 Support - Ensure your release dates with OpenLogic technical support, providing the same level of confidence for open source code as technical support for commercial products. Supporting hundreds of open source software packages for issues encountered in both development and production environments, OpenLogic technical support has you covered. Scanning - Knowing what, where, and how open source software is used within your organization is key to reducing risk and minimizing liability. Understanding the technical issues, licensing models, and security flaws before using open source code is critical to making good choices. Delivering applications on time, including open source that you're confident of, is achievable. Our scanning tool is a software-as-a-service (SaaS) governance platform for comprehensive governance and provisioning of open source software. Our tool scans source code as well as binaries to identify open source code and licenses – even when the open source code has been copied or modified. Services – Application Audit - Our Application Audit service analyzes internally-developed software for open source packages and identifies the bill of materials (BOM) and bill of licenses for open source components. After comprehensive code scanning, we aggregate the results to create comprehensive reports that help you make informed decisions about distribution. Application Certification – Provides certification that an application has been scanned for open source software and licenses, and that all open source license obligations have been met. With this certification, you avoid customer objections and potential litigation. License Obligation Analysis - Our License Obligation Analysis service uncovers the license information you need to understand open source license obligations and to reduce potential risks. We identify the licenses, obligations, and requirements associated with open source packages your organization uses. With this service, we provide comprehensive reports that give legal and compliance staff the information they need to make informed decisions about open source deployments and distribution. M&A Open Source Audit - Buyers, venture capitalists, legal and compliance teams, and other interested parties use M&A Open Source Audits to ensure that products are correctly licensed and free of intellectual property conflicts. Sellers can use the M&A Open Source Audit service to ensure mergers and acquisitions move forward smoothly and without asset devaluation. Cloud Services - We offer pre-configured stacks on the AWS Marketplace, Certified CentOS images, and, as always, trusted OSS support. Professional Services - We also offer best-practice advice and hands-on assistance. Consulting packages are available with varying levels of hands-on guidance and technical depth to address different needs and levels of complexity. http://www.openlogic.com/products-services
- #30 What attacks will these software components be exposed to? Will it be accessible over some type of network? Is remote access possible? Is the weakness easy to comprehend by the average attacker? How do we gauge the “security health” of code coming in? How do we achieve compliance? Lengthy process, unclear expectations, lots of resources Let’s not forget the regular bugs Can automated testing be more effective?