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
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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
50%
50%
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   >   >>


Mobile Banking Malware Up 50% in First Half of 2019
Kelly Sheridan, Staff Editor, Dark Reading,  1/17/2020
Active Directory Needs an Update: Here's Why
Raz Rafaeli, CEO and Co-Founder at Secret Double Octopus,  1/16/2020
New Attack Campaigns Suggest Emotet Threat Is Far From Over
Jai Vijayan, Contributing Writer,  1/16/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Oh, Bill? He's kind of old-school, but one of our best Cloud developers.
Current Issue
The Year in Security: 2019
This Tech Digest provides a wrap up and overview of the year's top cybersecurity news stories. It was a year of new twists on old threats, with fears of another WannaCry-type worm and of a possible botnet army of Wi-Fi routers. But 2019 also underscored the risk of firmware and trusted security tools harboring dangerous holes that cybercriminals and nation-state hackers could readily abuse. Read more.
Flash Poll
How Enterprises are Attacking the Cybersecurity Problem
How Enterprises are Attacking the Cybersecurity Problem
Organizations have invested in a sweeping array of security technologies to address challenges associated with the growing number of cybersecurity attacks. However, the complexity involved in managing these technologies is emerging as a major problem. Read this report to find out what your peers biggest security challenges are and the technologies they are using to address them.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-5216
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.9.0, 5.2.0, and 6.3.0. If user-supplied input was passed into append/override_content_security_policy_directives, a newline could be injected leading to limited header injection. Upon seei...
CVE-2020-5217
PUBLISHED: 2020-01-23
In Secure Headers (RubyGem secure_headers), a directive injection vulnerability is present in versions before 3.8.0, 5.1.0, and 6.2.0. If user-supplied input was passed into append/override_content_security_policy_directives, a semicolon could be injected leading to directive injection. This could b...
CVE-2020-5223
PUBLISHED: 2020-01-23
In PrivateBin versions 1.2.0 before 1.2.2, and 1.3.0 before 1.3.2, a persistent XSS attack is possible. Under certain conditions, a user provided attachment file name can inject HTML leading to a persistent Cross-site scripting (XSS) vulnerability. The vulnerability has been fixed in PrivateBin v1.3...
CVE-2019-20399
PUBLISHED: 2020-01-23
A timing vulnerability in the Scalar::check_overflow function in Parity libsecp256k1-rs before 0.3.1 potentially allows an attacker to leak information via a side-channel attack.
CVE-2020-7915
PUBLISHED: 2020-01-22
An issue was discovered on Eaton 5P 850 devices. The Ubicacion SAI field allows XSS attacks by an administrator.