Did you know that 84% of all cyber attacks target applications, not networks? What’s even more curious is that 80% of Internet of Things (IoT) applications aren’t even tested for security vulnerabilities.
It is 2018, and despite all the evidence around us, we haven’t fully accepted the problem at hand when it comes to software security. Because we haven’t accepted the problem, we are not making progress in addressing the associated vulnerabilities. Which is why after an active 2017, we are already seeing numerous new attacks before we leave the first quarter of the year.
So why the lack of progress?
The evidence that software is a primary attack point is everywhere, yet many choose to ignore security testing—at least for four out of every five IoT applications running today. Since IoT has proven to be an attractive attack vector, one would think that securing them would be of the utmost importance. Apparently not.
I’ve covered the mythology around limiting testing to perceived high-risk applications in other columns, so I will not cover that ground today. In summary, the evidence is overwhelming; there have been numerous cases where an application perceived as low-risk was used as the entry point to eventually breach high-risk applications to access high-value targets.
A testing regime that ignores large blocks of an organization’s software is no longer viable. However, doing cursory testing simply to check a box is not much better, and may create a false sense of security. Running a test because an auditor dictates that a test be run is not security. Running a test and addressing the findings is a step forward. You would be shocked by the number of organizations I have seen that generate lots of test results but never act on them.
Effectively evaluating secure code
The RSA Conference will be upon us in April, and a trip through the exhibit hall will find numerous application security testing (AST) vendors of all shapes, sizes, and approaches, each breathlessly promising you they are the one silver bullet you need to test your software security. At best they are telling you a partial truth, as the nature of today’s software demands multiple tests to comprehensively evaluate the security of any application. That is because applications contain three specific components where vulnerabilities can be found, and each must be tested in a different way for security testing to be complete.
1. The code you write. In spite of the adoption of open source and the move to agile methodologies, one thing remains constant: Your coders still write code. Source code analysis (static analysis) is designed to find security vulnerabilities and quality issues in your code as it’s being developed.
2. The code you get from open source. With the growing use of open source, the amount of code from external sources in any application is rising exponentially. This open source code may contain profound vulnerabilities that immediately become part of your software. Software composition analysis (SCA) detects open source and third-party component risks in development and production. It also identifies potential licensing issues in open source code used in your applications.
3. The running application. When code is deployed on the web, the runtime environment must be tested for vulnerabilities through dynamic testing. Testing the application in its running state will reveal problems simply not detectable by static analysis. For high-risk applications, many organizations step up their game by including the human element in the dynamic testing process in the form of ethical hacking.
Getting a sense of the problem here? Taking IoT as a widespread example, 80% of these applications are not tested at all. For the one-fifth that does receive some form of testing, the testing is likely incomplete. And we already established that many organizations find but do not fix problems.
No wonder the news in 2018 sounds all too familiar.
Until organizations shift their security priorities from endpoint and network security and start paying more attention to software security, I do not see the carousel stopping anytime soon. I estimate that at any large IT security conference, only 10% of the conference is focused on software security, while the traditional emphasis on perimeter defenses continues to dominate the conversation.
Practical steps to move forward
The best way to reduce the impact of security practices on development is to establish an emphasis on building secure code at the source by integrating secure coding practices into the secure development life cycle. This is a subject near and dear to my heart that I addressed in a previous column.
So how do you move your organization forward? While I do not have a silver bullet for you, I do have practical advice:
● Rebalance your IT security priorities and budgets to shift the emphasis where the problem exists—software security.
● Build a software security group that can then construct and manage a rational and comprehensive software testing program.
● Employ tools and programs that empower developers to write secure, quality software from the start. Building security in is a far better approach than trying to test yourself clean.
It is time for a balanced approach to IT security that places the appropriate emphasis on where you are being attacked: your software. The path to effectively addressing the problem is known, so make the hard choices to give the problem the attention it deserves. 2019 will be here sooner than you think.
Jim Ivers is VP of Marketing for the Software Integrity Group at Synopsys. Jim is a 30-year technology veteran who has spent the last ten years in IT security. Prior to Cigital, Jim was the CMO at companies such as Covata, Triumfant, Vovici, and Cybertrust, a $200M security solutions provider that was sold to Verizon Business. Jim also served as VP of Marketing for webMethods and VP of Product Management for Information Builders.
Tags:
http://feedproxy.google.com/~r/Securityweek/~3/iyuMxGLrhoU/why-do-vast-majority-applications-still-not-undergo-security-testing