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


Commentary
How SolarWinds Busted Up Our Assumptions About Code Signing
Dr. Jethro Beekman, Technical Director,  3/3/2021
News
'ObliqueRAT' Now Hides Behind Images on Compromised Websites
Jai Vijayan, Contributing Writer,  3/2/2021
News
Attackers Turn Struggling Software Projects Into Trojan Horses
Robert Lemos, Contributing Writer,  2/26/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: George has not accepted that the technology age has come to an end.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-23351
PUBLISHED: 2021-03-08
The package github.com/pires/go-proxyproto before 0.5.0 are vulnerable to Denial of Service (DoS) via the parseVersion1() function. The reader in this package is a default bufio.Reader wrapping a net.Conn. It will read from the connection until it finds a newline. Since no limits are implemented in ...
CVE-2009-20001
PUBLISHED: 2021-03-07
An issue was discovered in MantisBT before 2.24.5. It associates a unique cookie string with each user. This string is not reset upon logout (i.e., the user session is still considered valid and active), allowing an attacker who somehow gained access to a user's cookie to login as them.
CVE-2020-28466
PUBLISHED: 2021-03-07
This affects all versions of package github.com/nats-io/nats-server/server. Untrusted accounts are able to crash the server using configs that represent a service export/import cycles. Disclaimer from the maintainers: Running a NATS service which is exposed to untrusted users presents a heightened r...
CVE-2021-27364
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. drivers/scsi/scsi_transport_iscsi.c is adversely affected by the ability of an unprivileged user to craft Netlink messages.
CVE-2021-27365
PUBLISHED: 2021-03-07
An issue was discovered in the Linux kernel through 5.11.3. Certain iSCSI data structures do not have appropriate length constraints or checks, and can exceed the PAGE_SIZE value. An unprivileged user can send a Netlink message that is associated with iSCSI, and has a length up to the maximum length...