For this week’s “In the News”, research an article dealing with how secure code development practices (or lack thereof) affected a major software project; was the project more or less successful as a result?
Reader Interactions
Comments
Leave a Reply
You must be logged in to post a comment.
Elizabeth V Calise says
The Sorry State of Software Security: Secure Development is Key
Developers have been getting better at creating more secure software, but the same proportion of programs are vulnerable as a decade ago. Also, the risks have only increased. The impact of a security breach has increased because applications are the keepers of critical data and functions.
An unpatched vulnerability in the Apache Struts framework led to the theft of sensitive credit information on more than 143 million Americans. Software exploits stolen from the National Security Agency allowed ransomware attacks to spread widely. This shutdown some large organizations, including Maersk, Merck and Renault-Nissan.
A failure to make security a priority has resulted in widespread vulnerabilities. However, companies cannot prevent every bug, so they need to constantly test, fix and learn about security issues. Businesses must integrate security into development.
https://techbeacon.com/security/sorry-state-software-security-secure-development-key
Brock Donnelly says
Its hard to belive that 143 million Americans can have their sensitive credit information stolen and there is really no one responsible since Apache Struts is open source. The vulnerability (CVE-2017-9805) is a programming blunder that resides in the way Struts processes data from an untrusted source. Specifically, Struts REST plugin fails to handle XML payloads while deserializing them properly. All versions of Apache Struts since 2008 (Struts 2.1.2 – Struts 2.3.33, Struts 2.5 – Struts 2.5.12) are affected, leaving all web applications using the framework’s REST plugin vulnerable to remote attackers. It is is incredibly easy for an attacker to exploit this weakness: all you need is a web browser.
Folake Stella Alabede says
British Airways Faces Record-Setting $230 Million GDPR Fine (due to “poor security arrangements” that attackers exploited)
From what I read in the article, it seemed related to a man-in-the-middle attack, as the breach saw people visiting British Airways website being diverted to a fraudulent site, where details including name, billing address, email address and payment information were harvested.
Like banks, airlines tend to have “legacy” reservation systems that have their origins deep in the 20th century. While they have been continually updated, the structure is not as robust as newer IT systems.
Britain’s privacy watchdog has proposed a record-breaking $230 million GDPR fine against British Airways for violating the EU’s General Data Protection Regulation due to “poor security arrangements” that attackers exploited to steal 500,000 individuals’ payment card data and other personal details. Attackers were able to harvest customer details including log in’s, payment cards, and travel booking details.
https://edition.cnn.com/2019/07/08/tech/british-airways-gdpr-fine/index.html
Brock Donnelly says
Did anyone else hear the crowd roar? I see this as a giant victory for the change in customer privacy vs company incompetence. The fine seems beyond fair. I am enjoying the way the GDPR has been operating. Their fines are not light and each one makes an example for organizations focus on preventative means.
Elizabeth V Calise says
Between my own work experince and news articles – the legacy system cocnern pops up quite a bit. This falls onto BA not taking action. It is interesting because I would not be surprised that the security folks of BA said that this system needed to be updated and there are vulnerbailities and the ones who own the legacy system give multiple reasons why they could not update. So security probably recommended a few things they could do but knew there would be risk. However, that risk resulted in info stolen from 500,000 customers.
The scenario could have been different but I think this type of topic (legacy systems) happens often and sometimes security folks will bring it up but somehow it is bruhed under the rug.
Scott Radaszkiewicz says
NSA Releases GHIDRA Source Code – Free Reverse Engineering Tool
https://thehackernews.com/2019/03/ghidra-reverse-engineering-tool.html
Keeping with the software development theme, this is an article looking at it from the other end, the un-development of software. The National Security Agency(NSA) released GHIDRA, a free and open source reverse software engineering tool. The tool is designed to help companies reverse engineer software such as Malware to understand what it’s doing and how to combat it. The shocking discovery is that the released version had a flaw. If the program is run in debug mode, the system will listen on port 18001 on all interfaces. This allows anyone on the network to remotely execute code on the analysing system. Fortunately, the system does not start in debug mode, and you have to manually do so, but the flaw, nonetheless, exists. So much for testing and security!
Brock Donnelly says
Scott, I wonder if this “bug” in GHIDRA debug mode had a purpose when this was a classified agency tool. I cannot imagine for what. I guess it could also be a bit more nefarious to completely an accident. I find the whole project interesting and I am shocked to see something like this released to the public after it has been an agency secret tool for over 10 years.
Dima Dabbas says
Incident Of The Week: Toyota’s Second Data Breach Affects Millions Of Drivers
This article discusses how Toyota has had its second data breach which impacted 3.1 million of its customers. The reason behind the attacks was linked to hackers gaining unauthorized access to a server which gave them the ability to connect to the company’s network. The question remains as to how the hackers were able to get access to the server. Toyota believes that the hackers were able to get access through dealerships in Japan. Toyota could have avoided this issue by considering security in all its aspects from the organization at a high level to the various dealerships. The other issue was that two cyber attacks happened on Toyota within a limited period of time meaning that Toyota wasn’t able to fully respond and recover from the first cyber attack and its effects.
https://www.cshub.com/attacks/articles/incident-of-the-week-toyotas-second-data-breach-affects-millions-of-drivers
Sheena L. Thomas says
Oh wow, I drive a Toyota. I wonder how the attackers gained access to the systems. Could it have been an un-patched system, compromised account, etc? I will keep a watchful eye on the reason behind the attack because I really would like to know. I wonder if “I don’t know how the attack occurred” is an sufficient answer for legislators or law enforcement. It should be away for these companies to get penalize for not uncovering how the attack occurred.
Brock Donnelly says
Will this increase the requirements on SLAs for Toyota dealerships? Perhaps it should. It sounds like weakness came from various dealerships. Considering all the recent attacks over the last 9-12 months, would this 3 million+ of data stolen for Toyota really matter? 90% of the data must be duplicate from the Equifax incident. At what point does this type data becomes the kind of juice that is not worth the squeeze?
Duy Nguyen says
https://www.csoonline.com/article/3335120/15-secure-coding-practices-to-use-in-digital-identity.html
CAST, a software analysis firm analyzed 1380 applications and found an astounding 1.3 million code vulnerabilities. Much vulnerability was associated with the integration of third-party APIs for identity and access management. Integration with these APIs generally relied heavily on the security of the protocols used to communicate with the component.
Sheena L. Thomas says
I couldn’t find a article directly related to the question however, I found an interesting article regarding software development being a big threat to Cyber Security. For so long we have been constantly blaming humans or malware for cyber attacks, now more and more security professional are turing their attention to lack of security in code development.
Is poor software development the biggest cyber threat?
“The U.S. Department of Homeland Security (DHS) states that 90 percent of security incidents result from exploits against defects in software. That’s a big statement – and it implies that poor software development may be the biggest cyber threat of all.
You have to wonder if that’s an isolated finding in the context of DHS’s own experience – or do CISOs, IT security professionals, researchers and analysts, software developers, and application vendors agree?
The “Forrester Wave: Application Security Report”, which evaluates vendors for security and risk professionals, says many firms have rushed to bring applications online, building out consumer-facing websites, buying commercial off-the-shelf (COTS) products, and developing mobile applications to enable and engage with their customers and partners without thinking about the security of the application itself. As a consequence, businesses are exposing their most sensitive corporate and customer data to possible external threats and breaches.”
https://www.csoonline.com/article/2978858/is-poor-software-development-the-biggest-cyber-threat.html
Dima Dabbas says
Sheena,
That is very interesting that poor security development can be the biggest cyber security threat. It seems like organizations main focus is how to get an application up and running in the fastest time possible without focusing on security and the protection of the user’s data. As you mentioned, organizations are looking more into developing mobile applications to keep up with the rapid use of technology without focusing on security development.
Elizabeth V Calise says
Sheena,
This is a great article to share. Between school and work, you always hear about human error being the number one cause for hacks/attacks but poor software deevelopment could eaily be a runner up or number one. If you think about, companies are constantly software developing – so if they are not including security from the beginning in each software project, then they are creating a numerous amount of threats for themselves. Developers don’t focus on the security part. They are more cocnerned with the project running and working and making the project deadline.
Frederic D Rohrer says
Dependency upstream security is important, as highlighted by a recent security incident in which a good Node package suddenly turned malicious.
NPM (Node Package Manager) is a repository for Node.js server modules. Users can easily import packages to extend functionality of their servers. Packages are locally installed as opposed to a remote inclusion.
https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/
A very popular NPM package called event-stream was compromised when the original author allowed another coder publishing access on github. The unknown coder then pushed malicious code to the master branch, triggering NPM package updates and compromising all systems that updated their packages after.
The incident highlights the importance of open source code reviews.
Brock Donnelly says
I found an interesting blog post about the “famous laws of software development.” These laws were developed around the success or extreme failures of our founding computer science fathers. Some of these Laws directly relate to security. Check out; Brooks Law, Conway’s Law, Kerchkhoff’s Principle, and Linus’s Law.
https://www.timsommer.be/famous-laws-of-software-development/
Ahmed A. Alkaysi says
Thanks for sharing this site Brock, it’s a very useful list. The Brook’s law “Adding manpower to a late software project makes it later.” is it a good answer to Week 9’s question regarding when security should be involved in a project. If infosec get involved later in a project, then the project will become delayed.
Ahmed A. Alkaysi says
I thought this was a pretty relevant article. NIST is proposing a new framework for secure software development called (NIST SSDF). Although there are many frameworks regarding SDLC, not many address developing software securely. In practice, getting assurance for security is done at beginning. The NIST SSDF isn’t creating anything brand new. It recommends best practices from a number of existing sources. Proposed framework includes 19 best practices (grouped under four categories) for secure development. More information regarding this framework is below.
https://securityboulevard.com/2019/06/nist-proposes-secure-software-development-framework/
Jonathan Duani says
I think the best way to look at security within coding are with a lot of companies and their 0-Day updates. I think it is important to understand what and why these updates exist and the article is talking about 2 new 0-day patches that Microsoft pushed out. I think a 0-day update couple cripple a company if it is not patched right away a lot of the time. I think some of this stuff could be mitigated from a better QA and Microsoft not trying to push new updates and products before they are ready.
Source: https://www.infosecurity-magazine.com/news/two-zerodays-fixed-in-this-months/
Oby Okereke says
https://resources.whitesourcesoftware.com/case-studies/case-study-global-bank-automates-open-source-security-and-license-compliance-management
_______________________________________________________________________________________________
Case Study – Global Bank Automates Open Source Security and License Compliance Management
This article addresses how a bank turned to a security provider, Whitesource, a security, and reporting company that helps organization manage open source components by automatically and continuously scanning dozens of open source repositories, and cross-referencing this data directly against the open source components.
The Bank needed a vendor that could meet their specific requirements and allow them to become more agile within the confines of their more rigid structure. The vendor Whitesource was able to streamline the software coding practices that required the use of opensource codes.
Whitesource was able to provide continuous monitoring and detection thereby speeding up the application testing and development process for the bank’s developers. WhiteSource’s automated solution for
detecting open source components with known vulnerabilities, helps to limit the number of components that the Namk’s technology group would have to review manually, thus freeing up more time to focus on specific components that required attention.
For the Bank, implementing this new process with WhiteSource helped them to secure their environment and applications without the need for their developers to install any plugins or additional software, which had been a concern for them due to their heightened security posture.
Steve Pote says
I am pretty sure Google appends NIST to all my web searches now. If you are reading this you probably have at least one 800-XXX RevX document that plagues your dreams.
In this case ~lack~ of development frameworks, especially in the civilian contractors for government operations has lead to a proposed framework.
https://securityboulevard.com/2019/06/nist-proposes-secure-software-development-framework/
https://continuumgrc.com/chinese-hackers-military-contractors/