Q1. David, you are an expert on threat forecasting. Describe for us some of the biggest challenges that enterprises face in forecasting current and upcoming threats, focusing on the ones that matter the most to them.
As everyone in security knows, it is impossible to prepare for every potential risk, as the threat landscape is constantly evolving. To compound the issue, most enterprises still find themselves being reactionary and not allocating enough time to proactive security measures. One of the biggest challenges in deploying a proactive monitoring strategy is emulating realistic traffic, including legitimate and threat traffic, while not disrupting the customer and employee user experience. While there are a multitude of network devices that assist in defence, more often than not, organizations deploy devices with recommended policies. This often leads to unexpected behaviors and hidden gaps in security defences that can be compromised, resulting in inappropriate access and, at the extreme, breaches and data loss.
To address these challenges, enterprises that take a proactive monitoring strategy can move beyond basic compliance requirements and are able to focus their energy on fortifying their defences based on the current threat landscape and on reducing their cybersecurity risk. This allows enterprises to truly understand their unique environments, focus on the attacks that are relevant to their situations, and not be distracted by the volume of threat data, much of which is not relevant to them.
Spirent assists enterprises that are monitoring proactively with our data breach assessment solution. CyberFlood Data Breach Assessment enables customers to understand their environment better as well as to continually and safely assess their security posture, utilising fully emulated attacks, malware, and data loss prevention scenarios. Customers receive individualized intelligence that allows them to prioritize the specific areas of their environment that need to be addressed for maximum security efficacy. For customers looking for manual penetration testing in addition to automated data breach assessment, Spirent SecurityLabs offers a full suite of penetration services for devices, applications, and networks.
Q2. Eric, how has the growing adoption of DevOps, CI/CD, containers, and microservices impacted security-testing requirements? What new challenges have these models raised for app security testers?
DevOps and CI/CD have impacted security testing requirements by bringing security testing into the development cycle earlier. Anytime a unit test is run in a CI/CD model, a security assessment can be run at the same time. This benefits organizations by not only developing more security solutions but also identifying flaws earlier, which reduces remediation time and expense.
The same holds true for containers and microservices, as these are fundamentally miniaturized applications that are vulnerable to threats and exploits. These services require the same level of continuous testing, as they traditionally include APIs, web services, and other potentially vulnerable and often overlooked access points. Containers and microservices are often provided by third parties, which makes remediation dependent on actions taken outside the organization.
The increased adoption of these models requires adding security testing in planning and earlier stages of the application lifecycle. Development teams not accustomed to developing applications with security in mind may also need education in secure development best practices and the ultimate benefits to developers of adopting such practices. SecDevOps needs to consider that this strategy adds time to cycles for security testing but ultimately can reduce the full time-to-market of solutions that meet both business and security requirements. As a CEO, I am personally passionate about every employee considering the security implications of their actions and believe that as leaders, we must include security in our strategic business initiatives.
Q3. Eric, what's your advice for organizations looking to integrate security practices into their DevOps and CI/CD workflows? What's a good place to begin?
As organizations look to deploy SecDevOps as a strategy, they must first ensure that they have educated their development teams on secure development best practices and adopting a "security first" mentality. This may include a third-party security audit of current coding practices, including libraries used and data storage policies. Next, organizations need to consider the time added to cycles for security testing and the tools that result in a stronger security posture.
Choosing tools with a strong automation framework, well-defined APIs, and diverse coverage streamlines the adoption process and are a critical first step to successfully shift to this paradigm. As an example, many of largest global service providers leverage the Spirent CyberFlood Fuzzing solution during their CI/CD workflows to validate and certify CPE firmware releases for security. This radically reduces the risk of unknowingly deploying hundreds of thousands of residential gateways with security flaws. Static code analysis and penetration testing provide additional critical layers of testing to ensure improved visibility and the intelligence required for proactive remediation.
We are seeing increasing numbers of enterprises incorporating security practices earlier in the development lifecycle as they recognize the financial benefits of doing so and because the role of security in business decisions is evolving.
Q4. David, what do you want attendees at Black Hat Europe to know about Spirent's security services? What are you hoping they will take away from your organization's presence at the event?
Our rich history of supporting communication and network device manufacturers, service providers, and enterprise and government customers over the last eight decades provides us with the unique perspective and expertise to partner with our customers on their quest to reduce cybersecurity risk. With the newest addition to our security portfolio, CyberFlood Data Breach Assessment, customers are able to validate their defences and proactively identify areas for concern to allow for remediation prior to compromise. This solution was a child of our performance and security testing solutions in the labs of the largest network equipment manufacturers, service providers, and global 250 enterprises and the real-world expertise of our Threat Research group and SecurityLabs team's research on emerging threats and techniques.
We hope that attendees who visit our booth will come away seeing that we are their strategic partner, enabling our customers to capitalise on the latest technology trends, including IoT, mobility, and blockchain, while addressing the formidable cybersecurity demands of our connected world.
Q1. What should developers and enterprises be doing to reduce some of the risk associated with using open source software and components? What are some best practices with respect to open source component use?
For many years, Veracode has calling for greater attention to the fact that vulnerable open source software components run rampant within most software, and this presents significant risks to businesses. We recently produced our State of Software Security report, our ninth iteration, which found that 85 percent of all applications contain at least one vulnerability following the first scan and more than 13 percent of applications contain at least one very high severity flaw. In addition, organizations' latest scan results indicate that one in three applications were vulnerable to attack through high or very high severity flaws.
As organizations tackle bug-ridden components, they should consider not just the open flaws within libraries and frameworks, but also how they are using those components. By understanding not just the status of the component, but whether or not a vulnerable method is being called, organizations can pinpoint their component risk and prioritize fixes based on the riskiest uses of components.
It's not just important to know when a component contains a flaw, but whether that component is used in such a way that the flaw is easily exploitable. Data compiled from customer use of our SourceClear solution shows that at least nine times out of 10, developers are not necessarily using a vulnerable library in a vulnerable way.
If the pieces that make up the application are not secure individually, they will not be secure as a whole application -- no matter how many security solutions are applied after the fact.
Solving this problem proactively requires businesses to implement processes for tracking which open source components they use and how to patch them if necessary. Disclosed vulnerabilities are easily referenceable in the National Vulnerability Database (NVD) archives, and developers can search for the open source components used in their code. However, not each vulnerability is reported to the NVD, meaning it contains missing or incomplete information. Software teams can't rely on the NVD alone to keep track of new disclosures. It's important to have an active inventory of all open source components in use and a strong process for fixing them if needed.
Q2. From a tools and technology standpoint what are some of the requirements for making security testing an automated process of the CI/CD pipeline? What questions should you be asking when shopping for such tools & technologies?
Developers and security teams are both challenged to meet security goals in complex environments. Developers already need to manage many separate tools; new AppSec tools that do not integrate well or lack flexible APIs and customizable integrations are met with low adoption, high distraction and a steep learning curve. Likewise, security teams often seek to protect against AppSec vulnerabilities with a web application firewall and are challenged to integrate risk data and program metrics across disconnected AppSec tools without manual effort.
As more organizations move to DevSecOps and reap the automation and speed benefits, AppSec solutions need to keep pace with continuous software delivery.
It might come as a surprise to those in the security community, but many organizations haven't yet implemented AppSec or are just starting now. So organizations should start there – "is my code secure?" If that question is difficult to answer, it probably isn't secure. Once a business has an understanding of application security, they should be asking if the solution is integrated as a platform incorporating static, dynamic and interactive application security testing. From there, how well does that platform integrate with the other development, security and risk assessment tools the business is already using?
The AppSec tools that modern businesses should be looking to invest in should be cloud-based, scalable, and automated. They should offer continuous flaw feedback as code is written and secure coding education for developers. And often, businesses are in need of services for these tools so that they can best utilize the data in their scans and understand secure coding best practices with the help of experts.
Q3. What do you want attendees at Black Hat Europe 2018 to know about the state of application security testing and where it is headed over the next few years?
Security-minded organizations have recognized that embedding security design and testing directly into the continuous software delivery cycle is essential to achieving the DevSecOps principles of balance of speed, flexibility and risk management. It's a paradigm shift with an emphasis on security by design – building secure code from the start. Our State of Software Security report Volume 9 provided concrete evidence on the positive effects DevSecOps practices have on software security. We found the most active DevSecOps programs fix flaws more than 11.5 times faster than the typical organization, due to ongoing security checks during continuous delivery of software builds, largely the result of increased code scanning. The data shows a very strong correlation between how many times a year an organization scans and how quickly they address their vulnerabilities.
So the speed at which organizations fix flaws they discover in their code directly mirrors the level of risk incurred by applications. The faster organizations close vulnerabilities, the less risk software poses over time. In addition, the sheer volume of open flaws within enterprise applications is too staggering to tackle at once. This means that organizations need to find effective ways to prioritize which flaws they fix first. While many organizations are doing a good job prioritizing by flaw severity, it's also true that they're not effectively considering other risk factors such as the criticality of the application or exploitability of flaws.
I think we're entering an exciting time for AppSec because across every industry, businesses are seeing the value of secure code not just in development and security but also for the entire organization. It can enable better partnerships, help reduce risk of data breaches and improve efficiency of processes to the point that it offers a competitive advantage.
