Look to insecure software as the root cause of most major hacks

More high-level discussion, pressure on developers would mean fewer, less disastrous attacks

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someonePrint this page

After the recent Wan­naCry ran­somware attack that crip­pled sys­tems world­wide, peo­ple have start­ed to ques­tion the rea­son for the breach and what to do about it. End­point secu­ri­ty, improved patch man­age­ment, bet­ter busi­ness con­ti­nu­ity plan­ning, and a strong inci­dent response capa­bil­i­ty will all be held up as crit­i­cal to pre­vent­ing sim­i­lar future attacks.

But what was the root cause of the breach?

It may seem that orga­ni­za­tions not updat­ing (i.e., patch­ing) their sys­tems in time and leav­ing them vul­ner­a­ble to mal­ware like Wan­naCry is the prob­lem. But why did they need a patch in the first place?

Dig deep­er and exam­ine the rea­sons. The tech­ni­cal details of the patch point to a secu­ri­ty flaw in the way “SMBv1 han­dles spe­cial­ly craft­ed requests.” In oth­er words, the root cause is a soft­ware vulnerability.

Soft­ware vul­ner­a­bil­i­ties are rampant

Inse­cure soft­ware is to blame, as it almost always is in major hacks. Need proof? Take a look at the Metas­ploit exploit data­base. Metas­ploit is one of the most well-known exploit sys­tems in the world, and the data­base is full of code that takes advan­tage of soft­ware vul­ner­a­bil­i­ties like “com­mand exe­cu­tion,” “code exe­cu­tion” and “buffer over­flow.” These are all tech­ni­cal names of code flaws that allow an attack­er to com­pro­mise a remote sys­tem, includ­ing via mal­ware like WannaCry.

Relat­ed pod­cast: Secu­ri­ty by design: Embed pro­tec­tion dur­ing soft­ware development

Despite the fact that soft­ware is the basic issue, it is con­spic­u­ous­ly absent from the con­ver­sa­tions about next steps after an attack. Inse­cure code, built in-house or by third par­ties, is not men­tioned in the Nation­al Insti­tute of Stan­dards and Tech­nol­o­gy (NIST) cyber­se­cu­ri­ty frame­work, gets very lit­tle atten­tion in the indus­try stan­dard ISO 27001, and wasn’t fea­tured as a top­ic in the recent Nation­al Asso­ci­a­tion of Cor­po­rate Direc­tors’ Cyber-Risk Over­sight doc­u­ment. Most orga­ni­za­tions see it as a tech­ni­cal detail that doesn’t need to be addressed at such a high lev­el. The result, how­ev­er, is that it sim­ply gets left out of mind­share, effort and budgets.

Ask­ing the right question

Per­haps that’s because writ­ing secure code is extreme­ly dif­fi­cult. Yet harp­ing on the dif­fi­cul­ty of secure code doesn’t jus­ti­fy the top­ic being ignored. Nobody claims that secure soft­ware will ever be bul­let­proof, but the ques­tion we ought to ask is, “how eas­i­ly could this vul­ner­a­bil­i­ty have been pre­vent­ed in code?”

If peo­ple aren’t ask­ing, there is no rea­son to inno­vate or make the sys­tem­at­ic kinds of changes need­ed to build an infra­struc­ture of secure soft­ware. There is room to do much, much bet­ter col­lec­tive­ly than what we see today.

While the exact cod­ing issue from the Microsoft patch isn’t clear, a com­mon weak­ness ref­er­enced in the Metas­ploit data­base is “buffer over­flow.” We have known about buffer over­flows for years, yet a recent study found that state-of-the-art code secu­ri­ty scan­ners were only able to detect less than half of known buffer over­flows in code. Recent research indi­cates that many orga­ni­za­tions, includ­ing soft­ware ven­dors, rely on this kind of scan­ning as their pri­ma­ry, or even sole, method of secur­ing soft­ware. Rely­ing on tech­niques that find less than half of extreme­ly dan­ger­ous flaws is indus­try standard.

Change soft­ware devel­op­ment process

We can do much bet­ter by ask­ing soft­ware ven­dors to adopt more holis­tic secure devel­op­ment process­es. We can pres­sure ven­dors to move away from using unsafe pro­gram­ming lan­guages to pow­er our crit­i­cal infra­struc­ture. We can encour­age research to help build and pro­mote more secure vari­ants and alter­na­tives for those lan­guages. Most impor­tant­ly, we can make secure soft­ware the top-lev­el issue that it ought to be in cyber­se­cu­ri­ty frame­works, dis­cus­sions and regulations.

Let’s be clear: We will nev­er be total­ly safe from hack­ing or mal­ware. How­ev­er, if we want to dra­mat­i­cal­ly reduce the fre­quen­cy and impact of these attacks, the root cause must be addressed.

More sto­ries relat­ed to soft­ware security:
It’s cru­cial to mesh secu­ri­ty test­ing into ear­ly stages of DevOps projects
A case for mak­ing soft­ware more hack-resis­tant from the start
To get ahead of threat curve, boost secu­ri­ty dur­ing soft­ware development