Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Database Security
Authentication
Mobile
Privacy
Compliance
Careers and People
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
10 Common Software Security Design Flaws
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
JasonSachowski
JasonSachowski,
 User Rank: Author
9/3/2014 | 11:35:58 AM
Re: Secure Software Design
@billkarwin, i agree with the answer to your question about how writing secure code transcends to much more than just those born in the 90's.  For arguement sake, the same statement can be made about older and younger generations who have other collateral factors at play; such as they don't understand the technology or perhaps don't have the attention to detail.

@RyanSepe and @MarilynCohodas, I think you are right that we need to introduce the generations that follow us with the fundamentals of information/cyber/digital security much earlier than college or university.  Looking back at how fast technology has evolved in our lifetimes, one can only imagine what technologies the next generations will bring reinforces the fact that we have to educate eariler and make it a part of there every day lives.

I think software security in the education system today is looked at as somewhat of a security specialization and not a practice that is available in normal software development programs; in my experiences.  I will say that it's great to see the communities of InfoSec professionals actively involved in providing elementary schools with basic information/cyber/digital security but after this, it really needs to be continued as part of daily curriculum.
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
9/2/2014 | 10:40:50 AM
Re: Secure Software Design
Good point, Ryan. Security awareness really does have to be more baked into our educational system, doesn't it. And not just at the high ed level where newbie programmers are drilled at the most secure way to design apps. I think security awareness  about threats should be started in elementary schools in the same way children are schooled to avoid putting themselves in harms way in the physical world..
RyanSepe
RyanSepe,
 User Rank: Ninja
9/2/2014 | 10:07:18 AM
Re: Secure Software Design
@Marilyn Cohodas, I think this comes down to specialization within education. Until recently there were very few collegiate programs that dealt specifically with cyber security and information security. I have seen more and more pop up in recent years. Information Technology and Computer Science is a generalized overview of the subject matter. Basically outlining the different aspects on a lower level. If you were to specialize in an area you would receive a higher level of understanding and knowledge base. If they took programs that specialized in app development, I am sure in the core curriculum that app security would be one of the courses given not just an individual unit of a singular course. This would allow a more in depth learning process and transfer over into development.
Marilyn Cohodas
Marilyn Cohodas,
 User Rank: Strategist
9/2/2014 | 8:23:17 AM
Re: Secure Software Design
@RyanSepe and @billkarwin, your back-and-forth about the generation gap in secure software development & education is great -- and extremely interesting. But why aren't app designers coming out of computer science programs with a deeper understanding of the importance of building secure applications?   Why isn't that a given?
RyanSepe
RyanSepe,
 User Rank: Ninja
9/1/2014 | 5:13:04 PM
Re: Secure Software Design
I agree with you that education is the key here. The point I was trying to get across is just because someone is in the infancy of their career doesn't mean they don't have the theoretical components to write secure code. That is all. I was conveying that by the nature vs. nuture argument. If nature or experience is rivalled by nuture, which is the crux of the argument, than logically inexperienced (I mean this is in the sense of application) have the components to create secure code.

Your middle inquiry obviously uses reductio ad absurdum to berate the above statement. However, unfortunately you have heard of this being the case. With your example and with secure code. Many times its not until a breach happens where institutions decide there is a change needed to be made, and some software developers may be unaware of the hole in the first place. Hence new vulnerabilities. Is this due to a security flaw or a new attack strategy or maybe both? You cannot protect against something you are unaware of. (Heartbleed) It wasn't until this was discovered that a design flaw was even brought to light. This is highly unfortunate and our jobs as security professionals to try and show core value in security to other departments in the institution.

I agree with many of the points you make. Especially in the ways of education being the key. But to say that people that are surrounded by technology and have it ingrained in their daily lives opposed to a test group that has doesn't have it and is provided later in their lives is a frivolous and prideful notion.

I would say that security as a newer notion is valid, wherein people that are born in this generation will be the ones I speak of overall or the generation after. Security needs to a principle taught from a young age. Only than will people outside security be reached in its entirety.
billkarwin
billkarwin,
 User Rank: Apprentice
9/1/2014 | 3:40:29 PM
Re: Secure Software Design
Ryan, if people born in the 90's have such a higher proclivity to technology, then why aren't they writing more secure code? I see both young and old individuals unwittingly writing vulnerable code. It has nothing to do with what year they were born, and everything to do with how aware they are of the risks and the consequences.

If they aren't educated to be aware of secure coding practices, then what's the alternative? Wait until they have a personal experience of being responsible for a security disaster because of the poor code they wrote?

Just like becoming a convert to using antivirus software, or becoming a convert to making backups diligently, after losing all one's files.
RyanSepe
RyanSepe,
 User Rank: Ninja
8/31/2014 | 10:50:34 AM
Re: Secure Software Design
Good analogies. To some extent I do feel that education does play a big role here from the start.(Education is always the key in many situations, the better informed you are the better decisions can be made) As in younger analysts should be cognizant of security measures.

Similar to how if you are born in the 90's you have a higher proclivity to technology and its apsects because you were born in that time period of rapid growth. (Born it it) Might be a little biased and I normally don't like using generalized statements but statistically speaking that is the case. 

If we look at this from a scrum standpoint using an adaptive method to vulnerability assessment is the most conducive to the environment. Vulnerabilities and attack vectors deviate and adapt so the ones that are coding software need to adapt their focus as well.
billkarwin
billkarwin,
 User Rank: Apprentice
8/30/2014 | 2:25:49 PM
Re: Secure Software Design
Tim, your question reminds me of a story my mother experienced. She joined a group of volunteers at the local college to help young people register to vote (in the US this is not automatic, you have to fill out a form when you turn 18). She and her group did this every year. One year, one of the other women complained, "We've been helping to register students to vote for ten years! When are they going to learn to do it themselves?" The rest of the group had to remind her that every year, a new crop of students turn 18, and those individuals had naturally never had to registered before.

This is also the reason that well-known security vulnerabilities continue to be a problem, even decades after the remedies were first understood. The developer community gets a new crop of newbie programmers every year. They have never had to think about secure programming while doing class assignments, and they're even less likely to have done so if they are self-taught.

Yes, there are well-known fixes for old security flaws. At least, they're well-known to us experienced programmers. It's our responsibility to spread the word and educate all developers to program in a secure way by default.
DarkReadingTim
DarkReadingTim,
 User Rank: Strategist
8/29/2014 | 9:32:37 AM
Re: Secure Software Design
Great to see our old friend Neil Daswani in Dark Reading again! One of the things that strikes me each year when OWASP posts its Top 10 Vulnerabilities list is how many of the vulnerabilities are old. I mean, *really* old like SQL injection and buffer overflow. I wonder, why do these well-known vulns continue to occur with such great frequency, and isn't there something that could be done at the development level to prevent them?
macker490
macker490,
 User Rank: Ninja
8/29/2014 | 8:10:20 AM
cart and horse
remember: the O/S must protect the apps rather than the reverse.  you are always going to have a bad app someplace and if that can get an un-authorized update into the o/s you're toast.

you must start with a secure o/s and then proceed with the authentication of inputs particularly software but also data particularly anything financial or sensitive in nature.
Page 1 / 2   >   >>


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The 10 Most Impactful Types of Vulnerabilities for Enterprises Today
Managing system vulnerabilities is one of the old est - and most frustrating - security challenges that enterprise defenders face. Every software application and hardware device ships with intrinsic flaws - flaws that, if critical enough, attackers can exploit from anywhere in the world. It's crucial that defenders take stock of what areas of the tech stack have the most emerging, and critical, vulnerabilities they must manage. It's not just zero day vulnerabilities. Consider that CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilitlies in widely used applications that are "actively exploited," and most of them are flaws that were discovered several years ago and have been fixed. There are also emerging vulnerabilities in 5G networks, cloud infrastructure, Edge applications, and firmwares to consider.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-1142
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use URL decoding to retrieve system files, credentials, and bypass authentication resulting in privilege escalation.
CVE-2023-1143
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use Lua scripts, which could allow an attacker to remotely execute arbitrary code.
CVE-2023-1144
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 contains an improper access control vulnerability in which an attacker can use the Device-Gateway service and bypass authorization, which could result in privilege escalation.
CVE-2023-1145
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 are affected by a deserialization vulnerability targeting the Device-DataCollect service, which could allow deserialization of requests prior to authentication, resulting in remote code execution.
CVE-2023-1655
PUBLISHED: 2023-03-27
Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to 2.4.0.