DHS New “Top 25 Software Vulns” List – Experts Insight

By   ISBuzz Team
Writer , Information Security Buzz | Nov 28, 2019 12:22 pm PST

The Department of Homeland Security has just refreshed its list of the 25 Most Common Software Weaknesses: here’s the DHS intro link and the Mitre link with specific CWEs.

Subscribe
Notify of
guest
4 Expert Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
Javvad Malik
Javvad Malik , Security Awareness Advocate
November 28, 2019 8:38 pm

From a software perspective, this list looks right. However, much like other similar lists, such as the OWASP top 10, there is little change in the overall types of vulnerabilities which constantly make up the top issues.

This highlights the unfortunate reality that despite many efforts, security is not being embedded effectively enough within the developer community, or in enterprise assurance frameworks. It\’s not that we are unaware of how to identify and remedy the issues or prevent them from occurring in the first place, there appears to be a culture where getting software shipped outweighs the security requirements.

News like this is encouraging to attackers as even lesser-skilled ones know that without advanced techniques or custom malware abilities, they can still take advantage of age-old flaws to breach many companies.

Last edited 4 years ago by Javvad Malik
Roger A. Grimes
Roger A. Grimes , Data-Driven Defense Evangelist
November 28, 2019 8:36 pm

“Seventy to ninety percent of all malicious compromises are due to social engineering and exploiting unpatched software is involved in 20% to 40%. You would think that all software developers would be getting better at developing code with less exploitable security vulnerabilities. Some are, but most are not. This shouldn’t be surprising because most programmers are not taught about computer security and secure development lifecycle (SDL) programming techniques and processes in school. There are only a few colleges in the US that devote an entire course on computer security and secure program to programmers. Most cover it in a few hours as part of some other course, which of course means that it isn’t really covered. We get what we train for. All programmers should strive to learn as much as they can about SDL techniques, tools, and processes as they can. It will make them better programmers and more valuable to their employers. Best yet, they’ll get paid more and make more secure software for the world. It’s win-in. But this has been the case for decades and I’m not sure what catalyst is needed to get software development companies and programmers more self-interested in being more secure from the start. Things are pretty bad out there and have been for a long time. It’s a bit scary to think about what it would take to make them care more.”

Last edited 4 years ago by Roger A. Grimes
Ray DeMeo
Ray DeMeo , Co-Founder and COO
November 28, 2019 8:28 pm

It’s encouraging to see the DHS actively promoting the list of top software vulnerabilities compiled by NIST and MITRE. The biggest take-away is that memory buffer errors top the list with by far the highest risk score. These types of in-memory vulnerabilities are poorly understood, bypass conventional security tools, and are increasingly exploited in major attacks like WannaCry, NotPetrya, Industroyer and many others. While this list is helpful in raising awareness, we still have a long way to go to effectively protect against the most dangerous threats.

Last edited 4 years ago by Ray DeMeo
Jason Kent
Jason Kent , Hacker in Residence
November 28, 2019 8:25 pm

Often when these sorts of lists are refreshed we don’t see huge sweeping changes, usually there is a little bit of shifting around. After 8 years, from 2011 until now, I would expect a noticeable change and given they also changed the criteria they used for the list. I didn’t really see a huge change but what I see is characteristic of something we have been saying for a long time now.

The first 3 items on the list are about validating the input of an end user and controlling that input through the entirety of the system. As we have moved forward through time we have built more and more complex systems and are taking input from a user somewhere and using that input in other parts of the system.

Usually the user input is checked against a sanitization routine for the next upstream system. As the complexity of the systems grow, the complexity of the sanitization grows. In order to control workflows we have built systems that are comprised of services that are called with APIs. More APIs, more inputs, more places sanitization needs to have been done. All of this complexity and compounds and if the system architecture isn’t setup correctly the vulnerabilities will be found.

When it comes down to it software consumes data and emits data, controlling data inside the system is paramount. The top items on this latest “list of CWEs to pay attention to” are about what a user provides to the system for consumption. We have to ensure everyone knows the best sanitization for the input to their part of the system. Better architecture and understanding is needed to make sure we produce high quality software that is free of security flaws.

Last edited 4 years ago by Jason Kent

Recent Posts

4
0
Would love your thoughts, please comment.x
()
x