Join our LIVE Webinar
Tuesday, December 15th
So much cybersecurity time and attention is focused on software, while critical vulnerabilities are being exploited through hardware. It’s easy to fall victim to these rogue device attacks because hardware is viewed as inherently trusted. Recently these vulnerabilities are coming to light and beginning to be regulated as we’ve seen with Section 889 compliance.
However, simply avoiding known banned technology companies isn’t enough when it’s so easy for things to be white labeled and slip into your supply chain. The good news is that you can detect, inform, and mitigate these critical vulnerabilities to ensure compliance by directly checking any devices added to your network with a Rogue Device Detection Solution (RDDS).
In this webcast we will cover
• Supply Chain Vulnerabilities
• Weaknesses of commonly used security tools
• Ensuring Section 889 Compliance
• How to implement a Rogue Device Detection Solution (RDDS).
- Scott Lawler, Chairman/CEO at LP3
- Bob Gourley, CTO & Co-Founder at OODA LLC
- Ron Nixon, VP Global Defense at Polyverse Corporation
What is Section 889 compliance?
Section 889 is far reaching and extremely broad, Section 889(a)(1)(A) requires federal government contractors to certify to the U.S. government that any equipment, system or service it supplies to the U.S. government is devoid of any equipment or services from those banned Chinese technology or surveillance companies, and Section 889(a)(1)(B) further requires federal government contractors to certify to the U.S. government that their entire global supply chain, not just the part of the business that contract with the U.S. government, is devoid of equipment, system or service from those banned Chinese technology or surveillance companies.
Section 889(a)(1)(A) went into effect on Aug. 13, 2019. Section 889(a)(1)(B) is statutorily required to be implemented by Aug. 13, 2020.
Thursday, November 12th @ 10 AM PST | 1 PM EST
Join us to learn how the new NIST revisions will significantly impact your application security strategy as we present “NIST Application Security Revisions You Need to Know.”
We’ll discuss how NIST SP 800-53 Revision 5 contains two new IAST and RASP standards of interest to developers and application security (AppSec) teams:
Specifically, how these two notable quotes will directly impact the decisions AppSec and DevOps leaders and practitioners make when pursuing application security initiatives:
• “Require the developer of the system, system component, or system service to employ interactive application security testing tools to identify flaws and document the results.”
• “Implement [Assignment: organization-defined controls] for application self-protection at runtime.”